I upgraded one of my Photons (the easy to access one!) to 0.5.0rc1. I am able to use Blynk in a simple program (basically the one that comes with the library in the Build IDE), but when combined with my much more complex firmware, whenever Blynk.run() or Blynk.connect() is called and the library then attempts to connect to the Web, the Photon panics with a hard fault. I reverted to 0.4.9 and the code in question runs flawlessly and connects Blynk just fine.
Are there any changes on the top of anyone’s mind that might affect a library such as Blynk? I’m thinking threading, network related, anything that might cause an issue in more complex programs.
I will shortly try some tests to see if turning off SYSTEM_THREAD(ENABLED); makes any difference.
@legoguy thanks for the report! If you can reduce your complex firmware down to the simplest form that causes the hard fault, that would be most helpful. If you can then share this firmware with us, we’ll verify the issue.
Okay, this is a weird one. Prepare yourself for some head scratching.
Here’s the minimum required amount of code to reproduce this error. NOTE: This must be compiled with Particle Dev, and the latest version of the Blynk library (0.3.4 at time of writing), to cause an issue. If built with Particle Build, using the community included version of the Blynk library (0.3.3 at time of writing), you will (for some reason or other) end up with different compiled code that does not cause this issue to surface. Without further ado:
#define BLYNK_PRINT Serial
/* I copied all of the Blynk library files as provided at https://github.com/blynkkk/blynk-library/releases/tag/v0.3.4 into the same directory as the .ino.
* Include this header to set things up. */
#include "BlynkSimpleParticle.h"
#define BLYNK_AUTH "YOUR AUTH KEY"
void setup()
{
pinMode(D7, OUTPUT); // <--- comment this line...
waitUntil(Particle.connected);
Serial.begin(9600);
delay(5000);
Particle.publish("app/setup/begin", String::format("Blynk Test, running on Particle Firmware %s", (const char*)System.version()), 3600, PRIVATE);
Serial.println("BEGIN");
Blynk.begin(BLYNK_AUTH);
Serial.println("CONNECT");
Particle.publish("app/output/blynk", "Connect...", 3600, PRIVATE); // <--- OR this line to prevent a panic.
Blynk.connect();
Serial.println("WAIT");
if(waitFor(Blynk.connected, 5000)){
Serial.println("CONNECTED!");
delay(5000);
Blynk.notify("Application online!");
} else {
Serial.println("FAIL");
}
}
void loop()
{
Blynk.run();
}
So, if you look closely at the code I have called out two lines specifically.
Commenting either line will prevent a hard fault panic.
In my more complicated application, it seems that the Particle.publish() does not have an effect on the panic, but in this small application, it does. Not sure why. The line that was killing my complex app was pinMode().
I’m not really using Dev, so things could have changed since I last looked, but AFAIK Dev does always build for the default system firmware which currently still is 0.4.8 on Electron and 0.4.9 on the other Particles.
This would well explain why it works with Build but not with Dev.
None of the IDEs does currently detect the installed system version and automatically target that version. Build at least allows you to manually select the version, but I can’t find a way to do that with Dev.
Could you clarify how did you build Blynk 0.3.4 from upstream repository? I couldn’t compile it out of the box (though I never used it previously). Blynk library that is available on Particle Build seems to be based on this repo, which is maintained separately: https://github.com/vshymanskyy/blynk-library-spark
I basically started by adding the .h/.cpp files that I saw that the Build IDE version of the library was using to the root of my Dev project, and then included BlynkSimpleParticle.h in my .ino to get everything going (if you look at the source of the Build IDE’s blynk/blynk.h, that’s the same thing it does)
I like your first suggestion that reveals that the default of Particle Dev is to use 0.4.9. I will try compiling by particle cli and see if I can force the target to 0.5.0rc1. Probably not the best to use code compiled for 0.4.9 on 0.5.0!
It should be fine (in theory!) running an app compiled for 0.4.9 on 0.5.0 system firmware. But definitely try compiling the app on 0.5.0 to rule out any backwards compatibility issues.
You can do this in the CLI by passing --target 0.5.0-rc.1 at the end of the command line.
I just got a chance to try this, and compiling for 0.5.0-rc.1 fixed this issue entirely (but then https://github.com/spark/firmware/issues/947 reared its ugly head). Thanks for the help guys.
That’s good to hear - I will look at fixing that issue first thing on Monday.
In theory, you should be able to run a 0.4.9 compiled app on 0.5.0 firmware. If there are steps to reproduce this, I’d like to know about it since the system firmware is meant to be fully backwards compatible.
