Monitor 1 error and reboot after a couple of minutes

Firmware
1

I have a Monitor 1 utilizing Serial1 to communicate with an RFID reader. The firmware loads onto the M1 fine and runs for a few minutes (roughly 2 minutes) and then gives an SOS code. the SOS code is 7 flashes and the log outputs the message below:

0000100015 [ncp.esp32.mux] INFO: Starting GSM07.10 muxer
0000100016 [ncp.esp32.client] ERROR: Failed to perform early initialization

I saw that the SOS code represents "Exit" and was wondering what some likely causes could be. The firmware is based on the Monitor Edge firmware and has happened on 2 separate M1 devices.

2

Hi @mpalmer can you share some simple sample code that reproduces the error you're seeing?

3

From the status LED and device modes page:

This occurs if the standard C function abort() is called. In a Unix program, this would be used to abruptly stop the process. Device OS itself does not use this function, but the SOS can happen if user firmware calls abort() or _exit(). Since Particle devices only effectively support a single process, the user firmware, the effect is an SOS+7 and reboot. This could also happen if a library used abort().

I'd carefully check to make sure your RFID reader library doesn't have a call to exit() or abort() in it. There are no calls to it in Device OS or Tracker Edge.

4

Building on what is said above, I would comment out the RFID reader lib and see if it happens. If it does not happen, you have a better idea where to look.

5

For more info the RFID reader is just connected to USART on Serial1. I am working with some code someone else wrote and trying to figure out issues. It looks like the data is being read in as a char from the serial port and appended to a std::string. Current thread I'm pulling is that the string is getting too large (only happens if there is a large amount of RFID tags present but haven't gotten an exact limit) and when the tags are being appended to the string the append method is causing the abort (code frequently crashes right here). Are there any thoughts on the maximum string length for memory allocation? Each RFID tag is supposed to be 24 bytes.

6

On the Monitor One a std::string could possibly be as large 50Kbytes, but in practice fragmentation may make the limit smaller. But more likely the problem is:

  • Leaking memory, so you're running out of it.
  • Overwriting the end of the string, corrupting memory.
  • Corrupted serial data is causing unexpected behavior.
7

To explore if out of memory is the issue, you can check this code out:

image
image1914×714 77.1 KB

8

I didn't know about this, Thankyou!

1 Like