BGS5 based proto unresponsive | Telit Cinterion IoT Developer Community
November 6, 2018 - 4:09pm, 2385 views
Hello
We created a prototype board with a BGS5. It is supplied with 3.5V. The igt (on) signal is triggered, 300ms after power on.
We do not see anything coming out of ASC0.
USB does enumerate, but only 1 device, installs as modem. When connected to this usb modem's com port with realterm, it does not respond to anything.
Any advise on how to proceed would be very much appreciated.
After carefull review of the hardware, we did notice 1 thing: We connected pin 98 to ground, but hardware description states : do not use.
Can anyone please give more info on this pin 98?
Could this connection to ground be te reason why the module is not responding?
Hello,
In the default configuration AT commands are usable on ASC0 and USB0. Please see AT^SCFG command and "Serial/Interface/Allocation" parameter for more.
If USB enumerates maybe the problem is just that you don't send <CR> character to terminate and execute the command.
Regards,
Bartłomiej
Thanks for responding.
I've tried every possible combination of <CR> <LF>, ...
Different terminal tools (realterm, yat).
The device does not respond at all over the usb virtual port.
Can you also comment on the fact that only 1 device enumerates on usb?
Can you please commont on pin 98?
Is it somehow possible, we got devices without firmware?
Also, we don't see any activity on the statusled pin when powering on.
Hello,
In such case I think that connecting this pad to ground may be the source of the problem. According to hardware description it should not be connected at all. I don't have access to such internal documentation to check what exactly it is (anyway it is internal knowledge) - it might be prepared for some future use or reserved for some factory tests or something similar. In any case it is possible that this connection influences the module's behavior. So having only one USB might also be the result of this.
I wouldn't expect the module without firmware. As for status LED it is configurable with AT commands.
I think that you should start with removing this connection.
Best regards,
Bartłomiej
We figured out why the device goes in to this state. It is because of the DCD0 pin.
The docs say, if this pin is pulled to ground, the device goes into special state.
We do not pull to ground, but have it connected to a level shifter. This level shifter is in high impedence state at powe on. Still the BGS5 seems to 'see' it as pulled down and goes into it's special mode.
I attach part of the schematic that shows how the DCD0 pin is connected. The IO of U3 in this case have internal pullups. The level shifter U5 does automatic bidirectional level shifting. If its EN is not asserted, it's IO is high-impedant. So normally the BGS5 shoeld not 'see' an pull down. It does work normally if I remove R19.
The documentation does not clearly state how to use this pin. In all the reference designs I could find, this pin is not used. Do I need a pull-up on this pin?
Hello,
This pin can be configured as GPIO2 or DCD0 and has an additional functionality of switching the module into firmware download mode when connected to ground while the module boots. If you are not using this pin it should be kept open according to documentation.
Generally we do not recommend bidirectional level shifters. I think that you could use an oscilloscope to check the signal before and after the level shifter. It is possible that the module gets some low signal on that pin during the hardware initialization for example and that's why it gets into this special mode. So if you use it for ASC0 interface it is possible that you don't need it and can leave it open. If you use it as GPIO you could choose some other GPIO pin or add some additional pull-up.
Best regards,
Bartłomiej