BGS5T VCCREF reboots | Thales IoT Developer Community

Hello,

We have tested this on various modules and the problem will occur to each of them. The +5V powers a few chips, buttons, a transistor and VCCREF and the total power consumption is less than 10mA with everything activated. Even with +5V directly connected to VCCREF without any external PCB or connections(see image) the module will reboot continuously. Sometimes it will reboot before ^SYSSTART shows and sometimes it will let the midlet run a little before rebooting.

We use 2 inputs for reports and shutting down the module which are connected to +5V. We have 1 output which goes to a transistor to turn on a relay. Even with this disabled the problem persists. We use an external ADC and an external RTC. The ADC and RTC communicate via I2C.

After an unknown period of time (24 hours or less) without any power the module will begin to work again with +5V directly connected to VCCREF without the PCB. We have even simplified our circut removing the transistor/relay, buttons and chips. The circut now is simply +5V to a jumper that connects to VCCREF.

When VCCREFF is left hanging, not connected, everything works even while the rest of the GPIO is connected to the PCB. Even the buttons work when in this state. Once  we place the jumper to connect +5v to VCCREF the module starts rebooting. After this happens even removing the PCB all together and connecting +5V to VCCREF directly (see image) will cause the module to reboot continously before ^SYSSTART or randomly at the start of the midlet. The network activity or high power consumption due to the activity seems to be a factor because if the midlet is idle then the module is stable. Once I initalize the GPIO and start connecting to the network thats when the module tends to reboot.

Again to be clear, once the reboots begin the module will continue to reboot even when not connected to the PCB and only has +5V directly connected to VCCREF.

It is difficult to say exactly where in the code the module reboots because the module will reboot at different points. Sometimes the midlet isn't even running when the module reboots. Most of the time the module tends to reboot during an NTP sync which runs the following code. There are no other threads using the network or ATCOMMAND interfaces during this sync.

connURL = new StringBuffer(45);

        connURL.append("datagram://:9001");

        connURL.append(";bearer_type=gprs;access_point=");

connURL.append(gprs_apn);

connURL.append(";username=");

connURL.append(gprs_user);

connURL.append(";password=");

connURL.append(gprs_pass);

connURL.append(";timeout=50;");

try

        {

            //udp = (DatagramConnection) Connector.open("datagram://:9001", Connector.READ_WRITE, true);

        udp = (DatagramConnection) Connector.open(connURL.toString(), Connector.READ_WRITE, true);

            

            final byte[] buf = Ntp.toByteArray(new NtpMessage());

            

            Datagram sendDatagram = udp.newDatagram(buf, buf.length, "datagram://"+server+":123");

            

            udp.send(sendDatagram);

            

            Datagram receiveDatagram = udp.newDatagram(buf, buf.length);

            

            udp.receive(receiveDatagram);

            

            // Immediately record the incoming timestamp

            final double destinationTimestamp = Ntp.currentNtpTime();

            

            // Process response

            NtpMessage msg = Ntp.toMessage(buf);

            

            // Corrected, according to RFC2030 errata

            final double localClockOffset = Ntp.calculateLocalClockOffset(destinationTimestamp, msg);

            

            return (long) (localClockOffset * 1000);

        }

        catch (Exception e)

        {

            throw new Exception("Exception " + e.getMessage());

        }

        finally

        {

            if (udp != null)

            {

                udp.close();

            }

        }

All modules we use are prepared in the same manner using the following commands.

Commands that are run using the ASC0 interface at 1200 baudrate. These commands are run in this order.

WD=RST_REP,0,0

WD=RST_UART,0,0

WD=MIN_START_TIME,0,0

WD=ALWAYS_ON,0,0

WD=ON,0,0

Commands are run in this order.

AT^SPOW=1,0,0

AT^SJOTAP = "pwd",,,,,,,,,,,,

AT^SCFG="GPIO/****/DAI","gpio"

AT^SCFG="gpio/****/asc1","std"

AT+CFUN=1,1

AT^SCFG="Serial/Interface/Allocation","1"

AT+CFUN=1,1

at^SCFG="Userware/Autostart","","1"

AT^SCFG="Userware/Watchdog","1"

AT^SCFG="Userware/StdOut", "ASC0"

ATI1

Cinterion

BGS5

REVISION 01.100

A-REVISION 00.000.18

OK

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","0"

^SCFG: "Userware/Passwd",

^SCFG: "Userware/Stdout","asc0",,,,"off"

^SCFG: "Userware/Watchdog","1"