B524 SoM Instability: Slow Boot (1-Min White LED) and Unpredictable Restarts

Connectivity
1

Dear Particle Team

We are experiencing a consistent and concerning slow boot-up time and random reboots with all three Particle B524 SoMs (LTE CAT 1 EMEA + Bluetooth) we have attempted to provision for IoT door control in Denmark.

When setting up the devices via setup.particle.io, the process completes successfully. However, upon any cold boot (power cycling the device), the SoM exhibits a prolonged boot sequence: it consistently shows a constant white LED for approximately 1 minute before transitioning to blinking green for ~5 seconds, and finally reaching breathing cyan (online).

Crucially, after successfully booting and connecting, the SoM will randomly restart itself at unpredictable intervals (e.g., after 2, 5, or 10 minutes). Each of these restarts repeats the full 1-minute constant white LED boot sequence, followed by 5 seconds of blinking green, before reconnecting to breathing cyan. While the device eventually comes online and functions, this repeated, prolonged, and unpredictable boot sequence is a significant concern for reliability in a door control application.

Important note is that we have previously been successful in the exact same setup process - this only came resent.
We also have iOs device with the old Particle App installed and this still works like a charm.

What we have tried:

  • Successfully performed initial setup and Device OS update for all three SoMs via setup.particle.io.
  • Following the observation of the consistent slow boot-up and random reboots via setup.particle.io, we attempted a firmware/Device OS reset via particle serial update (Command Prompt). During this specific process, the device lost connection at 59%, indicating an issue with this method of local firmware flashing.
  • Ensured correct antenna connections: Cellular antenna connected to CELL u.FL port, 2.4GHz (Bluetooth) antenna connected to BT u.FL port.
  • Utilized a robust 12VDC power supply connected to the Particle Breakout Board, avoiding USB-only power.
  • Had both the power switch and Bat switch on during the process

Components/Devices Used:

  • Particle B524 SoM: Cellular SoM for IoT, LTE CAT 1 (EMEA) + Bluetooth.
  • Particle Breakout Board (M.2 Evaluation Board).
  • Particle Cellular Antenna: Wideband (698 Mhz - 2700 Mhz).
  • Particle 2.4GHz Antenna.
  • PowerWalker DC SecureAdapter 12V: Input 90-264 VAC, DC Output 12VDC ±5%, Max. Power 25W (2.1A), Battery: Lithium-ion 3.7VDC 2600mAh.
  • Standard USB cable (for setup and particle serial commands).

I tried the setup process on three different SoM devices all with the same outcome.
I tried with Device Restore USB | Tools | Particle tool without any luck. It also looses connection to the device during a restart / boot circle.
Only when I tried Device Doctor | Tools | Particle did the B524 SoM work as intended.
Here is the log from that:
Device ID: e00fce6861e27c9bba05a74c
ICCID: 89883070000013793300
IMEI: 868986060046753
IMSI: 232104851252929
Modem Manufacturer: Quectel
Modem Model: EG91
Modem Firmware Version: EG91EFBR06A07M4G
Modem Application Version:
Power Supply: Unknown
Battery: Unknown
Battery SoC: -1
Country: Denmark
Carrier: H3G
Access Technology: FDD LTE
Band: LTE 2100 (B1)
Cellular Global Identity:
0000000260 [system.nm] TRACE: Request to power on the interface
0000000261 [ncp.client] TRACE: Powering modem on, ncpId: 0x62
0000000262 [ncp.client] TRACE: Modem already on
0000000322 [mux] INFO: Starting GSM07.10 muxer
0000000324 [mux] INFO: Openning mux channel 0
0000000324 [mux] INFO: GSM07.10 muxer thread started
0000000326 [system.nm] INFO: State changed: DISABLED -> IFACE_DOWN
0000000625 [mux] INFO: Stopping GSM07.10 muxer
0000000675 [mux] INFO: GSM07.10 muxer thread exiting
0000000676 [mux] INFO: GSM07.10 muxer stopped
0000000676 [ncp.at] TRACE: > AT
0000001677 [ncp.at] TRACE: > AT
0000002678 [ncp.at] TRACE: > AT
0000003678 [ncp.at] TRACE: > AT
0000004678 [ncp.at] TRACE: > AT
0000005068 [app] INFO: Auto-connect disabled
0000005678 [ncp.at] TRACE: > AT
0000006678 [ncp.at] TRACE: > AT
0000007678 [ncp.at] TRACE: > AT
0000008678 [ncp.at] TRACE: > AT
0000009678 [ncp.at] TRACE: > AT
0000010678 [ncp.at] TRACE: > AT
0000011679 [ncp.at] TRACE: > AT
0000012679 [ncp.at] TRACE: > AT
0000013680 [ncp.at] TRACE: > AT
0000014680 [ncp.at] TRACE: > AT
0000015680 [ncp.at] TRACE: > AT
0000016680 [ncp.at] TRACE: > AT
0000017680 [ncp.at] TRACE: > AT
0000018680 [ncp.at] TRACE: > AT
0000019680 [ncp.at] TRACE: > AT
0000020680 [ncp.at] TRACE: > AT
0000021680 [ncp.client] ERROR: No response from NCP
0000021682 [app.cellinterp] INFO: processLog match ts=21680 category=ncp.client level=ERROR msg=No response from NCP
0000021683 [app] INFO: got no response from NCP
0000021681 [ncp.client] TRACE: Hard resetting the modem
0000022081 [ncp.client] TRACE: Waiting the modem to restart.
0000032681 [ncp.client] TRACE: Successfully reset the modem.
0000032682 [net.pppncp] TRACE: NCP event 3
0000032682 [net.pppncp] TRACE: NCP power state changed: IF_POWER_STATE_POWERING_DOWN
0000032683 [system.nm] TRACE: Interface 4 power state changed: 3
0000037683 [ncp.client] TRACE: Powering modem off
0000059038 [net.pppncp] TRACE: NCP event 3
0000059038 [net.pppncp] TRACE: NCP power state changed: IF_POWER_STATE_DOWN
0000059039 [system.nm] TRACE: Interface 4 power state changed: 1
0000059040 [ncp.client] TRACE: Modem powered off
0000059040 [net.pppncp] ERROR: Failed to initialize cellular NCP client: -210
0000059041 [ncp.client] TRACE: Powering modem on, ncpId: 0x62
0000059042 [net.pppncp] TRACE: NCP event 3
0000059043 [net.pppncp] TRACE: NCP power state changed: IF_POWER_STATE_POWERING_UP
0000059044 [system.nm] TRACE: Interface 4 power state changed: 4
0000069945 [net.pppncp] TRACE: NCP event 3
0000069945 [net.pppncp] TRACE: NCP power state changed: IF_POWER_STATE_UP
0000069946 [system.nm] TRACE: Interface 4 power state changed: 2
0000069947 [ncp.client] TRACE: Modem powered on
0000070948 [ncp.at] TRACE: > AT
0000070950 [ncp.at] TRACE: < OK
0000070951 [ncp.client] TRACE: NCP ready to accept AT commands
0000070951 [ncp.at] TRACE: > AT+CFUN=1,0
0000070956 [ncp.at] TRACE: < OK
0000070957 [ncp.at] TRACE: > AT+IFC=2,2
0000070960 [ncp.at] TRACE: < OK
0000070960 [ncp.at] TRACE: > AT
0000070962 [ncp.at] TRACE: < OK
0000070962 [ncp.at] TRACE: > AT+IPR=460800
0000070966 [ncp.at] TRACE: < OK
0000071967 [ncp.at] TRACE: > AT
0000071969 [ncp.at] TRACE: < OK
0000071969 [ncp.at] TRACE: > AT+CPIN?
0000071972 [ncp.at] TRACE: < +CPIN: READY
0000071972 [ncp.at] TRACE: < OK
0000071973 [ncp.at] TRACE: > AT+CCID
0000071974 [ncp.at] TRACE: < +CCID: 89883070000013793300
0000071975 [ncp.at] TRACE: < OK
0000071975 [ncp.at] TRACE: > AT+QDSIM=0
0000071977 [ncp.at] TRACE: < OK
0000071977 [ncp.at] TRACE: > AT+CMUX=0,0,7,1509,,,,,
0000071979 [ncp.at] TRACE: < OK
0000071979 [mux] INFO: Starting GSM07.10 muxer
0000071980 [mux] INFO: Openning mux channel 0
0000071981 [mux] INFO: GSM07.10 muxer thread started
0000072083 [mux] INFO: Openning mux channel 1
0000072135 [ncp.at] TRACE: > AT
0000072136 [ncp.at] TRACE: < OK
0000072137 [ncp.client] TRACE: NCP state changed: 1
0000072137 [net.pppncp] TRACE: NCP event 1
0000072138 [ncp.at] TRACE: > AT+QCFG="cmux/urcport",1
0000072139 [app] INFO: cellular is on
0000072140 [ncp.at] TRACE: < OK
0000072141 [ncp.at] TRACE: > AT+CGEREP=1,0
0000072143 [ncp.at] TRACE: < OK
0000072144 [ncp.at] TRACE: > AT+CFUN?
0000072145 [ncp.at] TRACE: < +CFUN: 1
0000072146 [ncp.at] TRACE: < OK
0000072147 [ncp.at] TRACE: > AT+CCID
0000072149 [ncp.at] TRACE: < +CCID: 89883070000013793300
0000072149 [ncp.at] TRACE: < OK
0000072150 [ncp.at] TRACE: > AT+CGSN
0000072152 [ncp.at] TRACE: < 868986060046753
0000072153 [ncp.at] TRACE: < OK
0000072154 [ncp.at] TRACE: > AT+CGMR
0000072155 [ncp.at] TRACE: < EG91EFBR06A07M4G
0000072156 [ncp.at] TRACE: < OK
0000072178 [ncp.at] TRACE: > AT+CCID
0000072182 [ncp.at] TRACE: < +CCID: 89883070000013793300
0000072183 [ncp.at] TRACE: < OK
0000072186 [ncp.at] TRACE: > AT+CGMI
0000072188 [ncp.at] TRACE: < Quectel
0000072189 [ncp.at] TRACE: < OK
0000072194 [ncp.at] TRACE: > AT+CGMM
0000072195 [ncp.at] TRACE: < EG91
0000072196 [ncp.at] TRACE: < OK
0000072199 [ncp.at] TRACE: > AT+CGMR
0000072201 [ncp.at] TRACE: < EG91EFBR06A07M4G
0000072204 [ncp.at] TRACE: < OK
0000072205 [ncp.at] TRACE: > AT+CGSN
0000072207 [ncp.at] TRACE: < 868986060046753
0000072207 [ncp.at] TRACE: < OK
0000072550 [ncp.at] TRACE: > AT+CFUN?
0000072552 [ncp.at] TRACE: < +CFUN: 1
0000072553 [ncp.at] TRACE: < OK
0000072554 [ncp.at] TRACE: > AT+CCID
0000072556 [ncp.at] TRACE: < +CCID: 89883070000013793300
0000072556 [ncp.at] TRACE: < OK
0000072557 [ncp.at] TRACE: > AT+CGSN
0000072561 [ncp.at] TRACE: < 868986060046753
0000072561 [ncp.at] TRACE: < OK
0000072562 [ncp.at] TRACE: > AT+CGMR
0000072563 [ncp.at] TRACE: < +QIND: PB DONE
0000072564 [ncp.at] TRACE: < EG91EFBR06A07M4G
0000072565 [ncp.at] TRACE: < OK
0000073049 [ncp.at] TRACE: > AT+CFUN?
0000073052 [ncp.at] TRACE: < +CFUN: 1
0000073053 [ncp.at] TRACE: < OK
0000073054 [ncp.at] TRACE: > AT+CCID
0000073057 [ncp.at] TRACE: < +CCID: 89883070000013793300
0000073059 [ncp.at] TRACE: < OK
0000073060 [ncp.at] TRACE: > AT+CGSN
0000073062 [ncp.at] TRACE: < 868986060046753
0000073063 [ncp.at] TRACE: < OK
0000073065 [ncp.at] TRACE: > AT+CGMR
0000073067 [ncp.at] TRACE: < EG91EFBR06A07M4G
0000073068 [ncp.at] TRACE: < OK
0000073550 [ncp.at] TRACE: > AT+CFUN?
0000073552 [ncp.at] TRACE: < +CFUN: 1
0000073553 [ncp.at] TRACE: < OK
0000073554 [ncp.at] TRACE: > AT+CCID
0000073556 [ncp.at] TRACE: < +CCID: 89883070000013793300
0000073557 [ncp.at] TRACE: < OK
0000073559 [ncp.at] TRACE: > AT+CGSN
0000073561 [ncp.at] TRACE: < 868986060046753
0000073562 [ncp.at] TRACE: < OK
0000073564 [ncp.at] TRACE: > AT+CGMR
0000073566 [ncp.at] TRACE: < EG91EFBR06A07M4G
0000073567 [ncp.at] TRACE: < OK
0000074656 [system.nm] INFO: State changed: IFACE_DOWN -> IFACE_REQUEST_UP
0000074659 [net.ppp.client] TRACE: PPP thread event ADM_UP data=0
0000074660 [net.ppp.client] TRACE: State NONE -> READY
0000074662 [ncp.at] TRACE: > AT+CFUN=1,0
0000074664 [ncp.at] TRACE: < OK
0000074665 [ncp.at] TRACE: > AT+CCID
0000074667 [ncp.at] TRACE: < +CCID: 89883070000013793300
0000074668 [ncp.at] TRACE: < OK
0000074669 [ncp.at] TRACE: > AT+CGDCONT=1,"IP","super"
0000074672 [ncp.at] TRACE: < OK
0000074673 [ncp.at] TRACE: > AT+CFUN=1,0
0000074674 [ncp.at] TRACE: < OK
0000074675 [ncp.at] TRACE: > AT+CREG=2
0000074677 [ncp.at] TRACE: < OK
0000074677 [ncp.at] TRACE: > AT+CGREG=2
0000074679 [ncp.at] TRACE: < OK
0000074680 [ncp.at] TRACE: > AT+CEREG=2
0000074681 [ncp.at] TRACE: < OK
0000074682 [ncp.client] TRACE: NCP connection state changed: 1
0000074682 [net.pppncp] TRACE: NCP event 2
0000074683 [net.pppncp] TRACE: State changed event: 1
0000074684 [ncp.at] TRACE: > AT+COPS?
0000074684 [net.ppp.client] TRACE: PPP thread event LOWER_DOWN data=0
0000074671 [system.nm] INFO: State changed: IFACE_REQUEST_UP -> IFACE_UP
0000074689 [ncp.at] TRACE: < +COPS: 0,0,"3 DK Twilio",7
0000074690 [ncp.at] TRACE: < OK
0000074691 [ncp.at] TRACE: > AT+CREG?
0000074693 [ncp.at] TRACE: < +CREG: 2,5,"C546","350281F",7
0000074694 [ncp.at] TRACE: < OK
0000074695 [ncp.at] TRACE: > AT+CGREG?
0000074697 [ncp.at] TRACE: < +CGREG: 2,5,"C546","350281F",7
0000074698 [ncp.at] TRACE: < OK
0000074699 [ncp.at] TRACE: > AT+CEREG?
0000074701 [ncp.at] TRACE: < +CEREG: 2,5,"C546","350281F",7
0000074702 [ncp.at] TRACE: < OK
0000074702 [ncp.client] TRACE: NCP connection state changed: 2
0000074703 [mux] INFO: Openning mux channel 2
0000074751 [net.pppncp] TRACE: NCP event 100
0000074752 [net.pppncp] TRACE: New auth info
0000074754 [net.pppncp] TRACE: NCP event 2
0000074754 [net.pppncp] TRACE: State changed event: 2
0000074755 [net.ppp.client] TRACE: PPP thread event LOWER_UP data=0
0000074756 [net.ppp.client] TRACE: State READY -> CONNECT
0000074756 [net.ppp.client] TRACE: State CONNECT -> CONNECTING
0000074757 [ncp.at] TRACE: > AT+CIMI
0000074758 [ncp.at] TRACE:0000075761 [ncp.at] TRACE: > AT
0000075763 [ncp.at] TRACE: < OK
0000075764 [ncp.at] TRACE: > ATO
0000075765 [ncp.at] TRACE: < NO CARRIER
0000075766 [ncp.at] TRACE: > ATD99**1#
0000075781 [ncp.at] TRACE: < CONNECT 150000000
0000075781 [net.ppp.client] TRACE: PPP phase -> Initialize
0000075782 [net.ppp.client] TRACE: PPP phase -> Establish
0000075783 [lwip.ppp] TRACE: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x58531c18> <ac
0000075789 [lwip.ppp] TRACE: rcvd [LCP ConfReq id=0x0 <asyncmap 0x0> 0000077232 [comm.protocol] TRACE: Reply recieved: type=2, code=0
0000077233 [comm.protocol] TRACE: message id 33 complete with code 0.00
0000077235 [comm.protocol] TRACE: rcv'd message type=13
0000077237 [comm.protocol] TRACE: Reply recieved: type=2, code=0
0000077238 [comm.protocol] TRACE: message id 32 complete with code 0.00
0000077239 [comm.protocol] TRACE: Updating system DESCRIBE checksum
0000077240 [comm.dtls] INFO: session cmd (CLS,DIS,MOV,LOD,SAV): 4
0000077627 [ncp.at] TRACE: > AT+CFUN?
0000077620000078177 [system] INFO: Cloud connected
0000078179 [ncp.at] TRACE: > AT+COPS=3,2
0000078181 [ncp.at] TRACE: < OK
0000078182 [ncp.at] TRACE: > AT+COPS?
0000078184 [ncp.at] TRACE: < +COPS: 0,2,"23806",7
0000078185 [ncp.at] TRACE: < OK
0000078186 [ncp.at] TRACE: > AT+CEREG?
0000078188 [ncp.at] TRACE: < +CEREG: 2,5,"C546","350281F",7
0000078189 [ncp.at] TRACE: < OK
0000078190 [ncp.at] TRACE: > AT+CGREG?
0000078192 [ncp.at] TRACE: < +CGREG: 2,5,"C546","350281F",7
0000078193 [ncp.at] TRACE: < OK

2

Solid white is not a software controlled state. The white LED turns on, then the device normally boots within a fraction of a second. If Devie OS was corrupted, the device would go into blinking yellow. Depending on the system mode, the device would either go into blinking green, breathing dark blue, or breathing white.

Solid white is rare, but it's caused by the device rebooting continuously before the bootloader loads. A more common scenario is blinking white, which occurs because of power issues; the device starts to boot, then does a brownout reset where the LED turns off, and the LED turns back on after boot.

I'm still guessing you have a power issue. Do you have additional load on 3V3? How much, and does it start immediately or wait until some later time or event?

One of the things about the Web Device Doctor firmware is that it delays before connecting to the cloud vs. the standard Tinker firmware which immediately connects.

3

Hi,
So you are saying it's definitly a hardware issue rather than a software, firmware device OS issue?

It's just strange that the exact same setup has been used last week to run a setup on a B524 without any issues.

However, I have tried to swap to a different power supply 12v2a with the same outcome - unfortunately.

I have recorded a video of what happens. Do note that the SoM Status Light turns white instant after flicking the power switch.
Aproximate 1 minut of constant white light -> 10-15 sec green blinking -> Breathing Cyan (connected).

Video of issue

4

Well since I don't know what's wrong, I can't rule out a software issue. However, where it's getting stuck is probably in the bootloader, which is an unusual place to get stuck. Also I don't know if it's a power issue, but that's the most common reason for a solid white.

As for hardware issues, it could be the SoM, but it could also the the PM-BAT. However, it's unusual that it would work with the web device doctor firmware if it were a hardware failure. The log of when it worked looks normal.

So basically the problem is not a known problem, and doesn't exhibit any common failure symptoms.

5

The SoM in the video is not the same as the one that has the web device docter firmware.

Just connected the SoM with the web device docter firmware and it connects instantly.

What can I do / What information can I provice you so we could troubleshoot further?

6

One thing that occurs during the boot phase after the white LED turns on is validating the Device OS image and user firmware. If there were an issue with the internal flash, that could cause odd behavior, but it would be unusual that it would eventually start working. Usually the device would just go into blinking yellow if there were a flash issue.

Since the cause is not known, the best thing to do is try other things until some useful data point occurs. For example, you could try Device Restore JTAG which will restore the entire built-in flash to factory state, which may or may not show anything. If you have a debugger, that might help, but if it's in the bootloader, it's hard to debug the bootloader, so it might not help. Some early debug messages can be output to UART serial which starts up before USB serial debugging, but even then, if it's bootloader or very early Device OS boot there won't be any messages.

7

In the current setup I tried Device Restore USB | Tools | Particle to install the latest Device OS and our firmware onto the SoM with Web Device Docter Firmware - and just as predicted it finished the process and when it gets to the restart phase it looses connection and I get this message: "Failed to reconnect to the device by USB. Click the Reconnect button to try again.".

Another setup run through setup.particle.io without any errors or failiures, however once our firmware is flashed to the SoM and it is restarted it is still 1 min of continous white light followed by green blink and then breathing cyan.

ALSO we still have a phone with the old particle app.
Using the setup process by opening the app, scanning the QR code on the SoM, and finishing the setup flow does the job. Using the app does not inflict the same issue as the setup via setup.particle.io and Breakout Board.

  • Could it be related to the Device OS? We are running 6.2.1 right now.
  • Could it be related to our firmware? I havent written the firmware but I know that the firmware I am trying with "v49.bin" has worked flawless prior to this issue.
  • Is it related to the fact that the devices is placed in my sandbox? I don't want to move them out until I know they work.
  • Has anything changed recently (previous 1-4 month) that could require an update in our own written firmware?
  • Could it be related to the breakout board? I have tried switched the DC power supply and I have tried different USB cables.
8

There could be an issue with Device OS, but it would not be a known issue. The release notesare available, and there should have been few changes that would affect the Boron. Most changes have been to Gen 4 (RTL872x).

It may be possible for user firmware to cause this behavior. If the user firmware had a STARTUP block or global object constructor that blocked with interrupts disabled, it would probably behave like that.

Just to be sure, your user firmware targets 6.2.1, correct? particle binary inspect can determine this. You can install firmware that targets an older version of Device OS, with a newer version of Device OS, but this is unusual.

If the device does not fully boot immediately, any of the web-based flashing tools will probably not be able to reconnect to the device, because they issue USB control requests to Device OS after leaving DFU mode.

You could rule out application firmware issues by flashing Tinker using the Particle CLI, particle flash --usb tinker with the device in DFU mode (blinking yellow). This will leave the same version of Device OS on the device.

9

We isolated the problem to be firmware, since the App setup stopped working aswell.

After looking into it, our developer took a dive into the code and started troubleshooting.

He did manage to find the error in the firmware code and he wrote:
"The issue with the one-minute boot time of the Particle device was caused by reading the EEPROM during the construction of our EEPROM handler class. We have now moved the EEPROM reading to the end of the setup() method."

Just wanted to post it here if anyone happens to face the same issues.

2 Likes
10

Hey, nice to hear that the issue is solved.
If the EEPROM class is/was global, there is this interesting singleton pattern that can help avoiding global/startup issues in the future:

If it does not apply, feel free to ignore my message.
Thanks,

2 Likes