resetReason() and resetReasonData() documentation

Firmware
1

I’ve added calling resetReason() and resetReasonData() to my startup function in order to try to help debug unexplained restarts. The documentation lists quite a few expected results for resetReason() but in practice many of those don’t seem to be implemented.

For example, pushing the reset button does result in values of 20:0 (reason:reasonData) which is RESET_REASON_PIN_RESET.

However, a successful firmware update results in 140:0 which is RESET_REASON_USER and is the exact same result that I get from calling System.reset() whereas the documentation says I should see RESET_REASON_UPDATE. I also never see RESET_REASON_UPDATE_TIMEOUT. I believe this is another case where I get RESET_REASON_USER instead.

Also, the results from resetReasonData() are not documented at all. In my case I’ve been getting a lot of RESET_REASON_PANIC (130:1). I’m still not sure what’s causing them but we think they might be power related.

3 Likes
2

Let me ping someone that might be able to help, @rickkas7 are you able to assist?

Kyle

1 Like
3

I’ve also been interested in using this data from the resetReason() function so that I can abstract some of the diagnostic reporting and reset functionality out of the particle console and into our server backend. Any thoughts since this was originally posted? I can try and dig through the source code and see if I can pin down any of this eventually too.

4

Did this not work for you?
https://docs.particle.io/reference/firmware/photon/#reset-reason

Also what FW version are you running? The original question is almost a year old.
And what exactly do you want to know/do?

2 Likes
5

Ah, I just looked at the latest response from a few weeks ago and not the original timestamp. Let me know if I should open a new topic.

Expected Behavior:
On the reset directly after successful firmware update I would expect the reset reason (both for last_reset and the System.resetReason() function) to be RESET_REASON_UPDATE.

Observed Behavior:
Both last_reset and System.resetReason() return code 140, User-requested reset after the reset immediately following a firmware update.

What I want to do:
I want System.resetReason() to return the code for RESET_REASON_UPDATE on the reset immediately following a firmware update, and for the console to also reflect that. Am I missing something / is part of my configuration in my firmware overriding the reset reporting behavior?

In my code as screenshotted below, I am sending a Particle.publish event with the same data I send to my server.

The top value (names are cut off) is a custom parameter that I set and retrieve with the resetReasonData() function. It will return “No Matching Reset Reason” if there was no data passed in on the last reset. Every reset initiated by my firmware explicitly passes in a resetReasonData value, so any time a reset returns “No Matching Reset Reason” it was a System firmware initiated reset as far as I can tell.

The next value down is a copy of the return value of System.resetReason(), with a string representation using the associations in the API doc you linked to.

Some potentially important configurations in my firmware for the below test:

  • System Firmware 0.6.3
  • I am using the Application watchdog with a timeout of 99 seconds, which is significantly more than the time between when the update began and the update came back online.
  • I am using SYSTEM_THREAD(ENABLED) and SYSTEM_MODE(AUTOMATIC). Resets and Updates are turned on, no configuration for those has been changed.
  • I have a handler for the reset event in a SINGLE_THREADED_BLOCK that prints a line to Serial, closes two SdFat files, delays for 100ms, and ends.

Screen Shot 2018-01-25 at 10.27.54 AM.png1946×1252 124 KB

2 Likes
6

I too am confused by this, I tried uploading a binary to the Particle cloud with the reset reason feature flag turned on. When I flashed it to a device by locking a specific device to this new updated firmware version, it posts a last_reset "user". I too am trying to key off of a firmware update.

This is exactly what I want as well but like @justicefreed_amper I do not see it happening

7

Not sure if you’re doing this or not, but make sure the previous firmware on the device had the feature flag turned on. Otherwise that data never would have gotten saved. Try marking the device as a development device and flashing the same firmware again and see if the behavior is as expected or not.

That said, totally possible you are seeing the same thing I did / do (I haven’t found any resolution to this).

8

@justicefreed_amper I verified by setting my firmware on the device to a version that has the feature flag enabled, and then uploading a new version as an OTA update. It updated but it still says the reason is “user”. It seems we are experiencing the same issue. @KyleG any backup?

Thanks for chiming in though and reporting the issue.

9

Here is an example:

~/C/s/code ❯❯❯ particle flash MY_DEVICE --cloud build/firmware.bin -v; particle serial monitor --follow
Including:
    build/firmware.bin
attempting to flash firmware to your device MY_DEVICE
Flash device OK:  Update started
Polling for available serial device...
Opening serial monitor for com port: "/dev/tty.usbmodem1421"
Serial monitor opened successfully:
0000104141 [app] TRACE: TEMP: 32.00
0000106144 [app] TRACE: TEMP: 32.00
Serial connection closed.  Attempting to reconnect...
Serial monitor opened successfully:
0000004046 [app] TRACE: REASON FOR UPDATE: 140
0000006095 [app] TRACE: TEMP: 32.00
10

I filed a bug:

11

@justicefreed_amper Just to follow up… looking at the code, I believe RESET_REASON_UPDATE only ever gets set when you do a serial update, so it wouldn’t get set if you do an OTA or USB update. For some reason I get an error whenever I try and flash via the “–serial” flag so I can’t actually test, ymmv.

1 Like