Sudden SOS fault on previously running code


#1

Hello !!!
I would like you to help me with a problem that is happening with my photon, I leave the video

Long time using the electron with the xbee, in fact the project consists of a network of sensors (5 nodes measuring temperature humidity CO2 and CO), and acquired data and could see them in the particle console, not to be due the problem but nothing changed the code, and probe with another photony makes the same error.

I hope you can help me.
Regards!!


Electron/photon drop in replacement for XBee?
XBee and Spark Core
#2

The photon documentation says that a one blink after SOS is a hard fault. You could have used an invalid pointer or corrupted memory or something else. Post your code or share your project, and I’m sure you’ll get more help. Without seeing that I’m not sure what we could do.


#3

Thanks for your help, this problem is very strange, I have not modified anything, I have months using that same code, and I only fail in a sudden way


#4

At first glance, you are accessing an array, “str”, beyond the array limits. I’m not sure how it would ever run without SOS faulting.

char str[36];
for (int i = 0; i < 50; i++) {
  dato = Xbee.read();
  str[i] = dato;
}

The array is only 36 elements but you access all the way out to 50 elements. That should rather be something like this which, checks the array bounds, and limits the for loop to the bounds of the array:

for (int i = 0; i < arraySize(str); i++) {
  dato = Xbee.read();
  str[i] = dato;
}

I’m not sure if you need to add the null terminator onto the char arrays before publish. Maybe @ScruffR can comment.

On another note, you should clean up your code with a proper indentation scheme so it is more organized and easier to read. Hopefully the bad indentation is just from a copy and paste. Also, the preferred method to share code is to copy the code text directly into the post and wrap with the special characters for proper formatting. Or using the “Share project” button on the “code” menu in the WebIDE. Both methods work a bit better than a screen capture.

For example, wrap your code like this:

```
code here
```

You can also add the C++ designation for better highlighting like this:
```cpp
code here
```


#5

@ninjatill, good catch! As for:

Particle.publish() DOES expect a NULL-terminated char string or String (which is defacto NULL terminated). :wink:


#6

Long time using the electron with the xbee, in fact the project consists of a network of sensors (5 nodes measuring temperature humidity CO2 and CO), and acquired data and could see them in the particle console, not to be due the problem but nothing changed the code, and probe with another photony makes the same error.

I hope you can help me.
Regards!!


#7

Thanks for your help, this problem is very strange, I have not modified anything, I have months using that same code, and I only fail in a sudden way


#8

@IrvingRangel. Perhaps you should start your own thread instead of double-posting: Electron/photon drop in replacement for XBee?


#9

I have split off your “thread-jacking” posts from the two other threads you double posted on.

I agree with @ninjatill, looking at that out-of-bound access in your code, I doubt this code was ever running safely.

BTW, I don’t see any reason for using ParticleSoftSerial on the RX/TX pins. These already have hardware UART support via Serial1. Why make it more complicated and less stable by using a pure software solution?


#10

Food for thought … I have experienced exactly the same issue - code which has worked on 6 systems for months suddenly starts failing with a hard fault after 15 minutes on one processor.

Code is too complicated to share in its current form but the comments made here will make me see if I can replicate the problem on a cut down version.

thanks


#11

@OziGreybeard, in the OP’s case, the hard fault was caused, most likely, by the unsafe way he was accessing his array… regardless of how long it ran successfully before faulting. Check your code for how you handle array access. You can try to eliminate the use of Arduino-style strings. (Rather, use c-style char arrays). Look for any other variables or object in memory that are large or have the potential to get fragmented or corrupted.


#12

Thanks for the tips. I could see the issue with the OP code and do not expect to have exactly the same issue.

I will look at the strings in particular. I am something of a newbie when it comes to C++ having been a FORTRAN programmer back in my younger days. I have sort of come up to speed with C++ and MATLAB over the past 18 months but am still very much a novice.

Code is 18 pages so does not lend itself to publication for review by the very helpful people in this community but I will see if I can track it down completely or to a small section of code.


#13

If you want to show the whole thing, you can post in github and share the link. Or if using WebIDE, you can use the “Share this Project” button and post the link. If it’s proprietary code, then you’ll have to boil down to just pertinent parts that cause the problem.