BGS5T VCCREF reboots | Thales IoT Developer Community
December 10, 2016 - 1:22am, 8522 views
Hello,
I have a simple PCB with a jumper used to choose between +5V from the module or an external 3.3V source. For some very strange reason once the module is connected to the PCB the module will reboot if +5V is connected to VCCRef. Even after removing and connecting +5V to VccRef the module will continue to reboot.
The reboots seems to coincide when using an internet connection, perhaps due to higher power usage. When connected to the PCB but without the jumper connected everything works and is stable. Even the inputs and outputs work correctly. This is even more strange because in this situation VccRef is not even connected to anything yet the digital inputs/outputs work. By change measuring VccRef when it is disconnted reads about +2V.
What is very concerning is that when VccRef is disconnected things work which not how it should be according to the datasheet. When +5V is connected to VccRef the module reboots normally during network usage, but not always but roughly %90.
We have used simple code and various midlets to rule out programming issues but the reboots continue. The module reboots without any warning or error message.
Thank you.
Hello,
I would like to add that 26 of the 40 modules have these issues.
Regards.
Hello,
Thank you for your report. It is really sad that you've had so many problems with our product.
I think that still the main and worst problem here is the device rebooting. I was hoping that this will not occur with the new firmware. But if it does we still are in the same place - both software and hardware can be to blame.
If you had some test application that reproduces this problem with the high probability on your side and it would not depend on any special hardware and it would be possible to run it on our side it would be the best way to test with the same application with our hardware and check if we'd be able to reproduce these problems also. If we'd really be that would give us a chance to investigate it.
We always advice a firmware update to the current release for further tests and debugging in case of unrecognized problems because the products are constantly improved and even if we even prove some problem in the old firmware there is always a chance that it will no longer exist in the new one.
So far I haven't heard about any problem with any "bad batch or lot" from the factory. If you are sure that some terminals are defective I'd still advice you to contact the provider for replacement.
Best regards,
Bartłomiej
Hello,
Unfortunatly we have more bad news. The vendor had 5 modules and we have problems with all of them. Again we have ruled out issues with our software because the modules will reboot even while doing a firmware update with absoultly non of our software installed.
The situation is much worst when +5V is connected to VREF. Are we using the latest firmware?
Thank you.
Hello,
This is very strange. How about the power source while doing the firmware update - were you using your own power source or some provided one?
Have you tried connecting the failing devices to the power source and hardware of the devices that were not failing?
Currently the latest official firmware version is BGS5 v01.100 arn0000021.
Regards,
Bartłomiej
Hello,
We are using the wall power adapter provided by the vendor. We also have used a stablized bench power supply. The problem persists independent of the power source.
Our vendor here in Portugal has confirmed that he was able to reproduce the issues we are having. Do you have any news of the situation?
Thank you.
Hello,
I wasn't able to reproduce this problem. That's why I have asked you if you have a test application that reproduces this problem with the high probability and if it would be possible to run it on our side.
If your vendor is able to reproduce it they should report this to Gemalto support with the test description and application. We need to be able to reproduce this problem on our side to further investigate it.
Regards,
Bartłomiej
Hello,
I have sent to you via email the code and compiled jad/jar.
We have purchased 2 EHS6 to try another platform however even with a brand new module with absolutly no code the module rebooted 4 ***** in rapid sucession. I only had a RS232 cables and a hyperterminal connected. I was using the wall adapter provided by our vendor and +5V was connected to VREF. Our code was never installed on the module and yet we can see the module rebooting.
I too have suspected the code as the culprite however we have encountered situations like this with the BGS5. I have disabled all watchdogs and we still see the module rebooting. If we remove the +5V to Vref connection the module stops rebooting and seems to stabalize. Once at this point we can connect +5V to Vref and the module stays stable for some time. After a random period of time, some***** minutes or hours, some***** days or weeks, the reboots return.
The code I sent you is not 100% complete however it should be stable. It is very difficult to develop code because any time there is a reboot I am left wondering if the code was responsible or if the module rebooted on its own. I believe the code properly handles its resources and releases resources on destroyApp, although the MIDlet during normal operation should never end its execution.
We have ruled out the root cause having to do with our PCB because we are able to replicate the problem with new modules using only +5V to Vref. Although the code is not complete we can rule out bugs in the code because we have seen both BGS5 and EHS6 modules reboot with factory configuration.
Thank you.
Hello,
I've tried your scenario with RS cable and simple application on BGS5T terminal with 5V connected to Vref. But I was unable to reproduce the reboots this way.
Here's my configuration:
at^scfg?
^SCFG: "Call/ECC","0"
^SCFG: "GPRS/AutoAttach","enabled"
^SCFG: "Gpio/****/ASC1","std"
^SCFG: "Gpio/****/DAI","gpio"
^SCFG: "Gpio/****/DCD0","std"
^SCFG: "Gpio/****/DSR0","std"
^SCFG: "Gpio/****/DTR0","std"
^SCFG: "Gpio/****/FSR","gpio"
^SCFG: "Gpio/****/PULSE","gpio"
^SCFG: "Gpio/****/PWM","gpio"
^SCFG: "Gpio/****/RING0","std"
^SCFG: "Gpio/****/SPI","rsv"
^SCFG: "Gpio/****/SYNC","std"
^SCFG: "Ident/Manufacturer","Cinterion"
^SCFG: "Ident/Product","BGS5"
^SCFG: "MEShutdown/Fso","0"
^SCFG: "MEopMode/SoR","on"
^SCFG: "Radio/Band","15"
^SCFG: "Radio/OutputPowerReduction","4"
^SCFG: "Serial/Interface/Allocation","2","2"
^SCFG: "Serial/USB/DDD","0","0","0409","1E2D","0059","Cinterion Wireless Modules","Cinterion BGx USB Com Port",""
^SCFG: "Tcp/IRT","3"
^SCFG: "Tcp/MR","10"
^SCFG: "Tcp/OT","6000"
^SCFG: "Tcp/WithURCs","on"
^SCFG: "Trace/Syslog/Otap","0"
^SCFG: "URC/Ringline","local"
^SCFG: "URC/Ringline/ActiveTime","2"
^SCFG: "Userware/Autostart","1"
^SCFG: "Userware/Autostart/Delay","50"
^SCFG: "Userware/Passwd",
^SCFG: "Userware/Stdout","asc0",,,,"off"
^SCFG: "Userware/Watchdog","0"
OK
ati1
Cinterion
BGS5
REVISION 01.100
A-REVISION 00.000.21
OK
at^spow?
^SPOW: 1,0,0
OK
I didn't configure the HW watchdog too.
I have also run your main application without any modifications. The application is quite complex and I've seen that it "eats" the exceptions - only some information is printed. For debug purposes the stack trace should be printed.
Also I've seen in the log that the application switches to the airplane **** while there's a sending data attempt in progress. The application is switching periodically to the sleep **** and there was not too many transmissions. I'll try to switch it off. After a few hours there was no more sending attempt but during the last attempt the application entered the airplane ****. Maybe you should provide that the sending is only done when there's a network available and the airplane **** is not started when there's a data transmission.
Finally I was also able to find 2 reboots in the logs. At this point I can't be sure that the application does not do it, but there would be some debug information according to the code if so.
This was only tested with 5V connected to Vref so far.
Best regards,
Bartłomiej
I'm experiencing the same problem.
When connecting +5Vout to VCCref on my BGS5T module it continuosly reboots every 15/20 seconds.
ATI1
Cinterion
BGS5
REVISION 01.100
A-REVISION 00.000.21
AT^SJAM=4
^SJAM: "a:/JRC-1.50.4.jad","Java Remote Control MIDlet Suite","Cinterion","1.50.4","1"
AT^SCFG?
^SCFG: "Call/ECC","0"
^SCFG: "GPRS/AutoAttach","enabled"
^SCFG: "Gpio/****/ASC1","std"
^SCFG: "Gpio/****/DAI","gpio"
^SCFG: "Gpio/****/DCD0","std"
^SCFG: "Gpio/****/DSR0","std"
^SCFG: "Gpio/****/DTR0","std"
^SCFG: "Gpio/****/FSR","gpio"
^SCFG: "Gpio/****/PULSE","gpio"
^SCFG: "Gpio/****/PWM","gpio"
^SCFG: "Gpio/****/RING0","std"
^SCFG: "Gpio/****/SPI","rsv"
^SCFG: "Gpio/****/SYNC","std"
^SCFG: "Ident/Manufacturer","Cinterion"
^SCFG: "Ident/Product","BGS5"
^SCFG: "MEShutdown/Fso","0"
^SCFG: "MEopMode/SoR","on"
^SCFG: "Radio/Band","15"
^SCFG: "Radio/OutputPowerReduction","4"
^SCFG: "Serial/Interface/Allocation","1","1"
^SCFG: "Serial/USB/DDD","0","0","0409","1E2D","0059","Cinterion Wireless Modules","Cinterion BGx USB Com Port",""
^SCFG: "Tcp/IRT","3"
^SCFG: "Tcp/MR","10"
^SCFG: "Tcp/OT","6000"
^SCFG: "Tcp/WithURCs","on"
^SCFG: "Trace/Syslog/Otap","0"
^SCFG: "URC/Ringline","local"
^SCFG: "URC/Ringline/ActiveTime","2"
^SCFG: "Userware/Autostart","1"
^SCFG: "Userware/Autostart/Delay","50"
^SCFG: "Userware/Passwd",
^SCFG: "Userware/Stdout","asc0",,,,"off"
^SCFG: "Userware/Watchdog","0"
Hello,
Is it happening always and without any user application and hardware connected or is there any special scenario?
Do you have more terminals and is it the same with all of them?
Currently A-REVISION 00.000.21 is still the latest public revision available.
Regards,
Bartłomiej