Precise meaning of "Assertion failure" (not "Attribution error")!

Firmware
1

Hi Folks,

rephrasing as I somehow replaced “Assertion failure” with "“Attribution error” in the original post How embarrassing! Talk about an Attribution error.

I am intermittently getting the SOS 10-blink code listed in docs as “Assertion failure”. However after hard searching, I have yet to find an explanation of exactly what this means. I have inferred from related threads on this forum that one cause can be dynamic reallocation of String objects, perhaps causing saved pointers to become invalid, but this is just a case, hinting at meaning but leaving me with an incomplete understanding of the underlying term.

Can anyone point me to a clear definition of this error code?

OS 0.7.0

2

Here is a post that better explains the SOS codes. The 10 blinks is an “assertion failure”. I think a divide by zero can cause it (among other things). Someone correct me if I’m wrong.

Edit: Looks like the docs were updated with the full list of SOS codes as well. @rickkas7, can the docs be updated for a quick explanation of what to look for with the 10-blink “assertion failure”? I’ve seen the same question on here a few times about that.

This post caused the assertion failure by not allocating enough stack for the watchdog… are you using the watchdog?

1 Like
3

AssertionFailure is triggered when a test for something that should never occur occurs, and there is no solution other than to SOS and restart.

Code might do this if the internal state is invalid and not what is expected, for example. Or something that should never happen and is non-recoverable, for example if the system thread cannot be created.

At the moment, all of the AssertionFailures are in things related to threads and the system thread, but that’s just because those are the only things that have been instrumented with an AssertionFailure panic.

2 Likes
4

I saw the watchdog/stack post, but the one that I suspect fits my case is this:

Passed pointers going out of scope and becoming invalid may be the reason, or the use of String methods that are "notoirious for fragmenting the heap".
I was doing both by publishing a String... but that's exactly what the following (flawed?) example in the Particle Guide to Webhooks does:

int led = D7; // The on-board LED

void setup() {
pinMode(led, OUTPUT);
}

void loop() {
digitalWrite(led, HIGH); // Turn ON the LED

String temp = String(random(60, 80));
Particle.publish("temp", temp, PRIVATE);
delay(30000); // Wait for 30 seconds

digitalWrite(led, LOW); // Turn OFF the LED
delay(30000); // Wait for 30 seconds
}

I am looking for a clear definition because, though perhaps I've solved my immediate problem by waving an inadequately understood work-around at it, I feel like without a deeper understanding of the problem, it will eventually re-emerge in another guise. I'm oldschool that way.

Update: converting to a global char buffer but continuing to use String methods still ends up crashing to 10 blinks after several hundred successful publications:

#define PARAM_PIN A4
#define PUBLISH_BUFF_SIZE 64 // plenty big
char PublishBuff[PUBLISH_BUFF_SIZE];
double ThisParam = 0;

void setup() {
}

void loop() {

 ThisParam = (float)analogRead(PARAM_PIN) / 4095.0;
 String(ThisParam).toCharArray(PublishBuff, PUBLISH_BUFF_SIZE);
 Particle.publish("Param", PublishBuff, PRIVATE);

}

5

Nope not using the watchdog. See (edited) lower post for VERY simple modified equivalent to the Webhook example, which also fails.