Photon crashes on more than two subscriptions

I’ve been having issues getting the code that worked on my Cores to work on my new Photons. I’ve found the problem to be that the Photon crashes if it has more than two subscriptions and receive an event.

I wrote the following code to show the error:

void handleLED1(const char* event, const char* data){
    digitalWrite(D0, HIGH);
    delay(1000);
    digitalWrite(D0, LOW);
    }
    
void handleLED2(const char* event, const char* data){
    digitalWrite(D1, HIGH);
    delay(1000);
    digitalWrite(D1, LOW);
    }
    
void handleLED3(const char* event, const char* data){
    digitalWrite(D2, HIGH);
    delay(1000);
    digitalWrite(D2, LOW);
    }
    
void handleLED4(const char* event, const char* data){
    digitalWrite(D3, HIGH);
    delay(1000);
    digitalWrite(D3, LOW);
    }
    
void setup() {
Spark.subscribe("led1", handleLED1);
Spark.subscribe("led2", handleLED2);
Spark.subscribe("led3", handleLED3);
Spark.subscribe("led4", handleLED4);

pinMode(D0, OUTPUT);
pinMode(D1, OUTPUT);
pinMode(D2, OUTPUT);
pinMode(D3, OUTPUT);
}

void loop() {
    Spark.process();
}

There is a LED connected to each of D0-D3 and the code wats for the events led1, led2, led3 and led4 and ights the LED for one second upon recieving this event.

The code works just as you would expect on the Core, the LEDs turn on for a second and life goes on, but on the Photon the following happens:

Code as above:
The events led1, led2 and led3 makes the LED light up for one second, turn of and then the Photon crashes and blinks SOS. The event led4 causes no reaction.

led4 subscription commented out:
The events led1, led2 and led3 causes the same behavior as above.

led3 and led4 subscription commented out:
Works as expected. The LEDs turn on for a second and the device does not crash.

It seems the crash occurs upon exit of the event handling routine. The Photon only crashes after the LED has turned off. If you increase the delay it will also delay the crash, so I’m pretty sure it is upon exit.

The documentation clearly says that both the Core and the Photon should be able to handle up to 4 events, but the Photon obviously can’t.

The code was written in the online Build IDE and flashed to the devices OTA.

I cant see any reason why this should not work on both devices. Since it works perfectly on the Core I can only assume this is a firmware bug on the Photon. Has anyone else found this problem?

2 Likes

this is a known issue:

you can try writing a handler like @ScruffR suggested and provided example

This can’t be the same problem, can it? I couldn’t find anything about devices crashing and blinking SOS, the issue is about webhooks and since it was posted in March i guess the problem was also on the Core?

My issue is only on the Photon and not while using webhooks. The code also works fine on the Core.

I realize that you could write some dispatch function in order to not have four subscriptions, but that is not really adressing the problem at its root. The documentation says four subscriptions should work and it works on the Core so why not on the Photon? Wouldn’t the correct way be to find what has been broken in the Photon firmware in compassion to the Core firmware?

@skoelden perhaps the issue is server-side and not firmware related, but I’m interested to see if photon will handle multiple subscriptions, so I’ll keep watching here too.

Good practice (despite not being reflected in the doc samples :unamused:) for the Core and the Photon would be to check the return value of Spark.subscribe() to make sure all the handlers get hooked up propperly.

Another thought might be to avoid delay() in the handlers, where possible. The handlers should be seen as “async” functions and as such should impose as little lag as possible on the “main” application code (inside loop() and between each call of it).

Having said this I do agree that this should work after all, so I’ll have some play with your code to see where it comes from and how to get around it.


@skoelden, I have performed some tests an can (unfortunately) confirm that there is something fishy, so I’ve passed my results on and the issue will be looked into by one of Particle’s best.
Opened issue #531 for this.

4 Likes