SOS Hard Fault recovery - Electron?

I have been using a Electron for a while… Well up to my third where by they are generating a SOS Hard fault code when a text message is received. I downgraded, flashed tinker, upgraded and re-flashed a working version of my code I know that works, and have been running on other Electrons for the last few months but same thing happens, On sending it a SMS I get a hard fault. They can connect to the server, send messages and work fine other hen the hard fault.

The code I am using is, is there any known way of making them like factory again? other then the methods I have tried above?

1 Like

Type of SIM card? Default Particle or another 3rd party?

You said you upgraded and downgraded firmware. It would be good to indicate the versions you tried, currently using at the time of the hard fault.

I also experienced the same issue - but it disappeared when I reduced the size of the many IF statements that processed a large number of input commands.

I had assumed it was the code associated with the IF statement running into memory errors. Natural assumption was excessive use of the ‘String’ variable causing memory errors. I may be wrong.

I think this statement:
STARTUP(cellular_sms_received_handler_set(smsRecvCheck, NULL, NULL));
Runs the code like an interrupt would, and needs to trigger a ‘flag’ to have the loop check for messages, rather than run a large function. I suspect the function is getting blocked by another system interrupt or something else happening at the same time.

Will do some more testing tonight and see what is going on.

@ScruffR - may have some thoughts on how well this code is written. I have reused code available elsewhere then customised it for processing the inputs… so I can’t say this is ‘perfect’ code.

PS: Bad idea for me to assume rather than test!

Sorry, 3rd party sim , Telstra in fact.
The version I’m using is 0.6.2. I tried it on 0.6.0 also but same issue.

@Cameron wow, that’s a quick reply. Mate your code was exactly what I was after, I modified it to get it to do the things I wanted and thought I had stuffed it up somewhere with my additional code but when I want back to the original same thing still happened. Up to my third Particle so hoping I can still use them once the code is working again. I was up to the point of thinking I had actually damaged the board in some way. I’m happy to help where I can and test code also and if @ScruffR has any ideas ??? I’m all ears!!! Ric

There are two tutorials mentioned in this post that might be helpful:

Another forum post also indicated someone backtracked on firmware versions but did not state which worked for him. Does not indicate what type of SIM card.

@cermak Thanks. I’m all over the Keep alive and have mine set at (120) which had never dropped connection on Telstra.

I tried back tracking to 0.6.0 and same issue. I started with 0.6.2 so the back tracking issue “should” not be mine. But I do like the way you think.

That is weird that your devices still act like that after you have removed the code… some things which I have found that may help…

  1. If you are using ‘products’ in - your product code will often be ‘reflashed’ onto the device again if it detects the device code has changed. You need to remove the ‘device’ from your product list. Could be that the old code is being pushed onto the device after your initial new code is on there for a few moments.

  2. Try clear the EEPROM… while the code doesn’t touch the EEPROM, I found in another thread that clearing it EEPROM.clear(); actually solved my problems with red SOS lights in other situations.
    When doing this, run the code from the setup() not loop().

  3. Reflash tinker (but not via web) use a USB cable and reflash using DFU mode. Use this command in the terminal when you have the device blinking yellow:
    particle flash --usb tinker

To enter DFU mode:

Your device will blink yellow when in DFU mode.
If your device is not blinking yellow, please:

  1. Press and hold both the RESET/RST and MODE/SETUP buttons simultaneously.
  2. Release only the RESET/RST button while continuing to hold the MODE/SETUP button.
  3. Release the MODE/SETUP button once the device begins to blink yellow.

If you haven’t installed the particle software on your MAC/PC - you may need to consider:

I hope that helps

1 Like

@Cameron Thanks…

Well I don’t actually have another working SMS code other then yours to test the SMS function. I have a basic one that turns on D7 light when if it receives any SMS at all and that works. But not one that actually reads and processes the message…

  1. No I’m not using products.
  2. Tried and no luck.
  3. Tried this a number of times now… no luck there either. :frowning:

I have the windows software including the flashing one which I use to downgrade it to 0.6.0.

I’ve commented on GitHub - hope I’m not wrong :blush: and this helps a bit, to start with.

1 Like


I removed the SMS processing from the interrupt. It now occurs in the loop.
The interrupt now changes a flag, the flag results in the ‘loop’ doing the SMS reading/processing.

This should remove any causes of SOS/Red light crashes. I found in similar actions it at times would result in unwanted blocking of system events… ideally - this shouldn’t occur when SYSTEM_THREAD(ENABLED); … but it did seem to still occur shrugs

I have made 1 of 2 suggestions made by ScruffR in the Github repo. I wasn’t able to fully make the adjustment of the buffer length suggestion changes - the code I’m reusing there isn’t my own. Would appreciate some help there to change it if possible :slight_smile: