Application incompatibility with firmware 0.4.6

Hey all,

I read somewhere that 0.4.6 should be backward compatible with apps written for earlier releases of the firmware. I had 4 photons and upgraded them and 2 of them started going into a red SOS flashing pattern (red LED, flashing SOS in morse code) followed by one red flash.

I tried many things including reflashing the app, pulling the 0.4.6 firmware down and recompiling my app against it, putting the Photon in safe mode & etc. Restoring the Tinker application caused the Photons not to die instantly, but reflashing my app after caused the same SOS pattern.

While I haven’t gotten it down specifically to the offending line of code, what seems to have gotten me past by the instadeath of my Photon. Specifically, I was defining a global variable which is an instance of the U8Glib library. That gets initialized very early on (since the constructor should be called even before main() as it is a global object). That, for some reason, worked in 0.4.5 but fails in 0.4.6. My temporary work-around was to replace the global object with a pointer instead and new() the object in setup().

I need to find out what part of the constructor was causing it to fail. It could also be that for global initializers the stack / heap may not be properly configured by that point? Not sure.


I can say for sure that your global objects are initialized after the heap has been initialized when running on the Photon, Globals in a single file are initialized in declaration order, while there is no initialization order between multiple modules.

The regression may not be something we can control - if you do find out what causes it, I’d be happy to investigate what caused the change, since it’s not intentional.

Hi @mdma

Well, after some tedious adding line by line, I’ve narrowed it down to a call that was in my global object while it was being initialized. It was tedious because many of the calls were only 1-2 lines of code, so there was no room for a nice binary search to find the cause of the crash). That being said, I’ve made a repro case for you and wrapped it with a pretty bow :slight_smile: You can test it out from the cloud-based IDE if you like.

// delayregressiontest046.ino
// Sauce -- testing a regression with SDK 0.4.6.
// A call to the HAL delay routines in a global constructor is causing the photon to go into a red SOS flash.

class DelayTest
    DelayTest(uint16_t duration)

DelayTest dt(10);

Didn’t even bother adding a setup() or loop() call, they’re not needed. Just comment out the HAL_Delay_Milliseconds call and there’s no failure.


Thanks for this and for the effort it took to get there! Very much appreciated.

Can you give me some background - what’s the reason why you want to add a delay at startup?

It’s part of the initialization sequence of my display in U8Glib. You will see several drivers at least have very short pauses in their initialization sequences.

U8Glib samples often create a global that drives a screen rather than new() one on setup. That is what was failing for me.

Have you figured out the cause of the regression yet? Might there be other fun to (timer? Pwm? Interrupt hooks?) that could trigger similar problems?


Thanks! This will be fixed in 0.4.7.

Great to hear.

Do you want me to test the fix?

Sure if you want to! I did add an automated test case to our integration test suite so I’m expecting you to find that it’s fixed also! :wink:

Oh, I’m sure my repro case is fixed, I can test out the U8GLIB sample I have to see if it breaks anywhere else…