Disable wakeup pin for sleep mode in electron (firmware 0.7.0)

Firmware
1

Hi All,

I currently have some electrons running on 0.7.0 firmware. They are located multiple states away from me so I have no easy access to physically visit the devices and upgrade them to the most recent firmware.

I would rather not flash firmware to the devices since that has been known to sometimes cause problems.

My electrons are solar/battery powered and are set to wake up every 55min and send data at the top of the hour. Then they go into SLEEP_MODE_DEEP for another 55min and repeat the process. I often have long awake times but have not yet lost data, suggesting that the electron wakes up early sometimes, possibly from a random HIGH signal on the wake up pin. This is draining my battery and causing power failure.

I was wondering if there was a way to disable the wake up pin in 0.7.0 firmware.

My idea is to assign the wakeup pin to a non-existent pin on the electron but I am not sure if that will work with SLEEP_MODE_DEEP.

My code would look something like:

System.sleep(D50, SLEEP_MODE_DEEP, 55*60);  //sleep for 55min

The above line of code of course does not work but I am wondering if there is code that will run that can have the same affect.

Thanks

2

SLEEP_MODE_DEEP (STM32 standby sleep) can only be exited by WKP (rising), elapsed time, or RESET.

There’s no way to assign WKP to a different pin for STM32 standby sleep. That’s the way the STM32 processor is designed. However, in Device OS 1.0.0 you can disable wake by WKP so only elapsed time is used. [Edited]

3

You can actually disable wakeup by WKP pin from STANDBY in 1.0.0: https://github.com/particle-iot/firmware/pull/1409

1 Like
4

@rickkas7 and @rickkas7,

Thanks for the suggestions. I have heard that upgrading firmware remotely is risky and can cause electrons to stall out (I can’t physically access these devices right now).

Should I be cautious about attempting a OTA firmware update or is that somewhat of a myth?

Thanks

5

You should always be cautious. For me, that would be testing OTA with a single (or multiple) dev device (that is a full product copy) multiple times (in all available configurations) before releasing to the wild. Your apprehension is a bit superstitious. Just build in testing and QA process into you upgrading procedure. You can't stop every edge case but at least you tried and can learn from any pitfalls through a documented best-practice.

3 Likes