I need to remotely update a few Borons (the only stable, long term connected ones I have, e.g., using 1.3.1-rc1) to switch from using bandwidth-heavy MQTT to using Particle.publish(). Frustratingly we can’t do binary with Particle.publish.
Changing the MQTT binary publish calls which never caused any crash to the following:
…causes kernel hard panic crash occasionally, but not every time, on 1.3.1-rc1, and not on 1.5.4 according to my testing.
So, is there any way in existence to upload 78-byte binary packets from the Boron on stable 1.3.1-rc1 without getting repeatable hard panic faults every few minutes?
Do you have a stack trace of exactly where it’s crashing? There’s nothing obvious in the code that would make any difference based on Device OS version. It uses Wiring String functions, but those haven’t been changed in 7 years.
If you don’t have a source debugger set up, you could also split the process into two parts, encoding the binary data in Base64 in one test, and uploading a static 104 byte Base64 string in another to make sure it’s the encoding that’s crashing and not the publish queue.
Which SOS code is it crashing with? SOS+1 (hard fault)?
I would probably not use encodeString(). That allocates the string on the heap which isn’t a particularly efficient way to do it. I would use the encode() function instead and preallocate a buffer as a global variable that’s big enough for the encoded buffer plus 1 byte for the null terminator. That should be 105 bytes for 78-byte binary data.
@rickkas7 Thank you Rick for this; I will start by trying encode + stack preallocated buffer. Also using the retained memory for PublishQueueAsynch seems to be allowing me to not miss minutely packets by allowing the OS to recover from these crashes fast enough before the next packet, while remembering the last. Still not good design to have constant crashes so I will try this; thanks.