@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.

@bucknall I am able to corrupt the file system pretty easily. Running 1.7.6FW ATM. It seems to be when the program has a file open and an error occurs. What is the file system running on these boards? It doesn't appear to be a journaling file system. It is way too easy to corrupt the file system and have it erase the whole flash. I am developing a BT application that can update any file on the device and really need protection against this type of failure. I'm already doing a double buffer approach with the file writes so I have a good copy of the target file before deleting the original and renaming the file. The issue is resetting the board in the middle of a file write causes any manor of flash corruption. Before someone says "don't do that", I try very hard to design my system to recover from any type of errors. The cardinal rule is that there should be no way to brick a unit doing an update. To that end, I test every kind of failure during updates to make sure the device remains in a operating state.

@jmarcelino '1.6.12.b1'