Bug with System.on on Electron?

Troubleshooting
1

Hello,

I tried to load the same program on an Electron and a Photon device. While the code load and run perfectly well on the Photon device (0.4.9). It refuse to compile for the Electron device unless I comment out the line:

  void setup() {
...
  //System.on(reset, reset_handler);
...
}

If I don’t do that, I get the following error through the WebIDE:

    stabilitytest2.cpp: In function 'void setup()':
stabilitytest2.cpp:104:33: error: invalid conversion from 'void (*)()' to 'void (*)(system_event_t, uint32_t, void*) {aka void (*)(long long unsigned int, long unsigned int, void*)}' [-fpermissive]
 
                                 ^

In file included from ../wiring/inc/spark_wiring.h:47:0,
                 from ./inc/application.h:36,
                 from stabilitytest2.cpp:2:
../wiring/inc/spark_wiring_system.h:101:17: error:   initializing argument 2 of 'static bool SystemClass::on(system_event_t, void (*)(system_event_t, uint32_t, void*))' [-fpermissive]
     static bool on(system_event_t events, void(*handler)(system_event_t, uint32_t,void*)) {
                 ^

My Electron device was running on v0.4.8-rc6 first, I did upgrade it to v0.5.0-rc.1 to see if it would solve the issue. But I still face the same problem. Is there a difference of behavior between Electron and Photon for System functions? or is it a bug on the Electron device?

Also, I don’t know if this is related or not. But I’ve three timer than run in my code:

Timer timers(10000, print_every_10s);
Timer timerm(60000, print_every_minute);
Timer timerh(3600000, print_every_hour);

On the Photon, all three work perfectly well. On the Electron I’ve valided that the timerm does work (using Serial.print). but not the timerm (and I’ve not waited an hour to test the timerh).

Thank in advance for any help received on this issue.

2

In the devices list, expand the Electron device and make sure Building with Firmware has 0.5.0-rc1 selected, not 0.4.8. That’s the error you’d get if you had 0.4.8 selected.

Upgrading the system firmware is a separate thing from the version the application is being targeted for. Usually they’re the same but in general you should be able to flash an app built for 0.4.8 on 0.5.0-rc1. But in this case, you need an API that’s only in 0.4.9 and later, which is why you need to target 0.5.0 on the Electron in order to get it to compile.

1 Like
3

Thanks rickkas7,

In fact I though that I did int the WebIDE:
-Go to device
-Select the electron device
-Select Building with firmware 0.5.0-rc.1
-Go back to code tab
-Click on the cloud logo to download the firmware
-Flash the firmware using “particle flash --serial firmware.bin”
-check Serial print to confirm fw version:
Code: Serial.printlnf(“System version: %s %d”, System.version().c_str(), System.versionNumber());
Result: System version: 0.5.0 327680

But then I want back to the WebIDE and checked the device Building with firmware: ? And I saw that 0.4.8 was selected. So it seems that the WebIDE is rolling back my changes as soon as I leave the Device section. And I’ve no way to force it. I’ve tried to clear the cache to no avail.

I’ll open a ticket with particle.io support.

4

If you actually had upgraded to 0.5.0-rc.1 (which does not happen by merely serial flashing the app bin file you downloaded from Build - you'd need to flash three seperate bin files) then you could work around this known issue of Build, by just selecting 0.4.8 as target system, OTA flash a tiny dummy sketch like this (which wouldn't use too much of your precious data quota)

void setup() { }
void loop() { }

Build will realize the presence of the new firmware version and update the info in the target drawer.
If this doesn't help you probably haven't upgraded yet.

A better way to readout your devices state would be

particle serial inspect

BTW: Either you forgot to mention the fact in this list ...

... or should also press build between 3 and 4.
Otherwise you'd just download a previously built binary regardless of your selected target.
And if Build doesn't already report 0.5.0 present it won't build a 0.5.0 binary which you could download.

2 Likes
5

In in fact, I did upgrade my Electron device using the procedure given in GitHub Firmware releases page. So, the device should be in fact upgraded to 0.5.0-rc.1.

I’ve tried your work around. But it does not seems to solve the issue. I may have forgotten to state the my device was already seen as running 0.5.0-rc.1 in the WebIDE.

And also I’ve already a ticket open with the Support about the electron device been seen originally as a Photon device instead of an Electron device in the WebIDE (now solved) which may be linked.

Note:
Concerning the remark about step 3 and 4, When I mouse over the cloud logo it says:

Is this incorrect?

6

And I forgot, here the

$ particle serial inspect
Platform: 10 - Electron
Modules
  Bootloader module #0 - version 7, main location, 16384 bytes max size
    Integrity: PASS
    Address Range: PASS
    Platform: PASS
    Dependencies: PASS
  System module #1 - version 12, main location, 131072 bytes max size
    Integrity: PASS
    Address Range: PASS
    Platform: PASS
    Dependencies: PASS
  System module #2 - version 12, main location, 131072 bytes max size
    Integrity: PASS
    Address Range: PASS
    Platform: PASS
    Dependencies: PASS
      System module #1 - version 12
  User module #1 - version 3, main location, 131072 bytes max size
    UUID: <REMOVED>
    Integrity: PASS
    Address Range: PASS
    Platform: PASS
    Dependencies: PASS
      System module #2 - version 10
  empty - factory location, 131072 bytes max size
7

The problem is you are still building to 0.4.8 - see the dropdown “building with firmware”. Change that to 0.5.0-rc.1

8

Yep, that right! but your recommendation won’t work as the WebIDE auto-rollback to 0.4.8 (see my explanation in my second posts in this thread).

9

Yup, that was the reason for my thought and hence the suggestions.

Without the info, that your device was already seen by Build as having 0.5.0-rc.1 on it and hence assuming it'll still been seen as 0.4.8, you would have had no chance to build for 0.5.0-rc.1.
With that in mind, I was led to assume that the binary downloaded might have been a precompiled one (still present from another build) instead.

10

Thank you ScreffR for all the help.

I will try to be more precise next time. As I’m not certain to understand all the underlying processes of the system, it is always hard to know was is enough information to share and when it is not enough.

1 Like