Call function on shutdown/reset?

Is there any way to call a function when a Core/Photon is being reset by the RESET and/or MODE buttons?

I saw something about Hal_Core_Mode_Button_Pressed, but what I really want is something that could run at reset time. Intended purpose is to clear an LED strip so that lights aren’t shining all through a reboot.

I suppose if it came down to it, I could rig up an external button. But I’m being lazy!

Try this: What is the earliest moment after startup to light a LED, and how do I get there?

1 Like

But I don’t want code to run at startup, I want something that will happen just before an actual reset starts… My use case is:

I’m working on LED strip animation code. I frequently need to flash new code (either OTA or DFU).

When I either press the buttons to start to enter DFU, or I start flashing OTA, my code stops running, leaving the LEDs in whatever state they happened to be in.

I’d like to be able to run some sort of shutdown function, which could call strip.clear();;, before the halt occurs.

Is there an interrupt I can tie into for these events?

As I mentioned before, I tried using Hal_Core_Mode_Button_Pressed, but it doesn’t kick in when you are using the RESET/MODE button combo.

You’d have to implement an external “shutdown” button (or possibly repurpose the setup button as such.

The reset button is wired directly to the reset pin of the CPU.

If you want to get super cute - you could create your own custom bootloader that accomplished this on reset.

Let me repeat: “lazy!”. :wink:

So forget the reset button. What about catching the start of an OTA update? Is there a hook I can use to run user code before OTA is initiated? If not, I think it could be a useful feature. Even if there was some limitation like “the user code only has 10ms to complete, then the firmware update starts anyways!”

Indeed - there should be a variety of interlocks available around OTA (including: “thanks for offering, not now”, “let me just safe the < whatever > I’m connected to, now you can go ahead”, to “Now is a good time, anything for me ?”) - I have no visibility into if/where these are on the feature roadmap, sorry - someone from Particle will have to chime in on the mechanics.

@mdma has been working on System Events which are callbacks you can register for on specific things. I don’t think this work is completed yet but he has the general frame work and a few sample events working. Here’s the enum that describes what you can register for:

enum SystemEvents {

    // begin/progress/end
    // wifi, cloud, ota_update
    // custom flags

    wifi_listen_begin = 1<<1,
    wifi_listen_update = 1<<2,
    wifi_listen_end = 1<<3,
    wifi_listen = wifi_listen_begin + wifi_listen_update + wifi_listen_end,
    setup_begin = wifi_listen_begin,
    setup_update = wifi_listen_update,
    setup_end = wifi_listen_end,
    setup_all = wifi_listen,
    network_credentials = 1<<4,
    network_status = 1<<5,
    cloud_status = 1<<6,             // parameter is 0 for disconnected, 1 for connecting, 2 for connecting (handshake), 3 for connecting (setup), 8 connected.. other values reserved.
    button_status = 1<<7,            // parameter is >0 for time pressed in ms (when released) or 0 for just pressed.
    firmware_update = 1<<8,          // parameter is 0 for begin, 1 for OTA complete, -1 for error.

    all_events = 0x7FFFFFFF
1 Like

Cool! Okay, I’ll stop filling the forums up with questions about this, but I’ll look forward to being able to do that sort of thing in the future.

This is scheduled for 0.4.7 in a couple of weeks.


No - it’s all good, @dougal.
It’s important to understand the use cases, and talk through how features like this are envisaged to work - preferably before/during implementation.

1 Like