Avoid LoPy to restart after deep sleep

[synapse_]

Hello everyone!

I'm using PyTrack + LoPy + Deep Sleep Shield. Here's what I'm trying to do :

• Join a LoRaWAN network
• Get my GPS position
• Transmit data
• Put the device into deep sleep for 30 seconds

Everything works just fine. But I noticed that the device was restarting once the deep sleep period was over. I guess that normal and I also guess that doing a restart consumes much more energy than continuing the code execution, isn't it ?. So my question is :

Is there a way to prevent the device from performing a restart and that code execution continues normally after the deep sleep period?

Note : I'm using the go_to_sleep() method of the PyTrack class instead of the DeepSleep class because the device consumes 17 uA in the first case and 2 mA in the second.

Thanks in advance for your help!

[seb]

@marcobenini

@marcobenini said in Avoid LoPy to restart after deep sleep:

@seb Thenk You for the useful link.
There could potentially a problem with lora.nvram_save() and fast memory wear due to too high writes or I am wrong?
For example: if the NVS (flash memory) is a 100k write cycles unit, use deep sleep and if I send a message every 2 minutes, than in about 140 days the 100k writes is reached.

From my understanding of the esp32 forum thread linked previously the NVS is wear leveled so depending on the amount of data it would last longer but for such frequent writes, I would recommend either an SD card or some sort of external RAM that remains powered.

Maybe some parameters could not be re-written, but some, like packets counters change every time a LoRa message is sent.

There are functions in the firmware for this already: https://docs.pycom.io/chapter/firmwareapi/pycom/network/lora.html#loranvramsave

but these also use NVS, this should only need to be done when the device is going into and out of sleep

Will Pycom change the functions also to include external memory (for example I2C / SPI FRAM, ...)?

There are no plans to do this at the moment, but this doesnt prevent you from adding it yourself for your application.

Could the parameters that change be transferred to the microcontroller used for sleep control?

I'm afraid the memory on this microcontroller is already running tight, I doubt this could be added.

In LoPy4 how are managed the LoRa parameters, does them remain stored in the Semtech LoRa chip?

See above

I ask since I looking to put together a solution for a test project which end devices have to be battery power, collect data, but send periodically to save power.

[MarcoBenini]

@seb Thenk You for the useful link.
There could potentially a problem with lora.nvram_save() and fast memory wear due to too high writes or I am wrong?
For example: if the NVS (flash memory) is a 100k write cycles unit, use deep sleep and if I send a message every 2 minutes, than in about 140 days the 100k writes is reached.
Maybe some parameters could not be re-written, but some, like packets counters change every time a LoRa message is sent.

Will Pycom change the functions also to include external memory (for example I2C / SPI FRAM, ...)?
Could the parameters that change be transferred to the microcontroller used for sleep control?

In LoPy4 how are managed the LoRa parameters, does them remain stored in the Semtech LoRa chip?

I ask since I looking to put together a solution for a test project which end devices have to be battery power, collect data, but send periodically to save power.

[seb]

@marcobenini

This discussion here should help shed some light:
https://esp32.com/viewtopic.php?t=3990

[MarcoBenini]

@seb Thank You very much.
Do You know the number of write/erase cycles of the NVRAM on LoPy or LoPy4?

[seb]

@marcobenini

You can store you own values in the NVS by using the functions documented here:
https://docs.pycom.io/chapter/firmwareapi/pycom/pycom.html#pycomnvssetkey-value

[MarcoBenini]

@synapse_ said in Avoid LoPy to restart after deep sleep:

I'm using PyTrack + LoPy + Deep Sleep Shield.

You don't need to use the "deep sleep shield" if You use the PyTrack.
Pytrack has its own microcontroller that switches off power to LoPy board, the same is done by "deep sleep shield", but You are not using it, so You have a passenger onboard that does nothing and consumes power :-)

The root of LoPy, WiPy and SiPy high power consumption in deep sleep mode is an error in hardware design.
link text

So the "workaround", used in "deep sleep shield", PySense and PyTrack, is to simply cutting the power to the LoPy board.

Also for the other boards, not affected by the hardware design problem, for example LoPy4, there is the problem that the "main.py" is restarted at each wakeup.
The reason is that micropython interpreter has to be relaunched each time.
So, if there is no implemented state save / recover system, all that is in volatile memory will be lost when going in deep sleep.

In recent firmware version was introduced for LoRa utilities to save in NVRAM the state of some LoRAWAN parameters (joined status, network keys, packet counters, ...).

I don't know if developer can use something similar to store needed data in NVRAM.

an alternative can be to use a FRAM module (SPI or I2C) to save some of the data. Great advantage of FRAM is that even if powered off it retains data, also the number of read/writes is very very large, so no problem like the ones with EEPROM.
For sure the memory size are not so big.

[synapse_]

Thank you very much for your answer ! It's too bad we can't do otherwise :(

Thank you again and have a nice day.

[jcaron]

@synapse_ during deep sleep the processor is fully powered down, including all RAM, registers, etc. It’s not possible for it to resume execution.

I’ve wondered in the past if some kind of “hibernation” with all state saved to flash and restored on boot could make sense, but I think that would mean quite a lot of work (beyond the RAM there’s the state of peripherals etc.) and I’m not sure that would save a lot of power given the amount to write to and read from flash (if anybody has any data points on this topic I would be interested to hear them).

So at the moment you don’t have much choice. Note that even the “native” deep sleep will behave similarly, as even though the ESP32 is still powered, significant parts of it (including most RAM I believe) is shut down.