Gpy brownout operation corrupting flash.



  • Hi kindly Pycom experts,

    We are a charity developing a G01 and L01 gardening sensor and learning platform to engage students with STEM concepts through the medium of gardening. The devices run on 3xAA batteries with the intention being to let the batteries run down and the device eventually fail. When they run out (every 6 months) we'll get the teacher to replace them.

    However we have encountered the following conditions when the power reaches brownout levels:

    • the flash storage blanking and losing main.py and other non-frozen-bytecode files.
    • the entire flash corrupting leading to a continuous boot cycle we can't reflash our way out of.

    We believe this is being caused by some code that writes any full exception traces to a file. We also have 2KB FRAM on board so can move that to be stored there. But we have these questions:

    • Even if we never write to flash, could flash memory still get corrupted in a brownout state?
    • Does the micropython os ever write to the flash of its own accord?
    • Could writing NVS key/value config data also cause flash corruption in a brownout state?

    Our hope is that if we never ever write anything to flash then we'll be ok. Im sure these are pretty basic questions for experienced type so appreciate any assistance you can provide.

    Cheers Scott.



  • Hi Andreas,

    Thanks for your pointers. We have found through investigation that the issue is nothing to do with how we are using the filesystem (which is now not at all) but to do with the pycom firmware itself.

    With our code built with version 1.20 onwards any brownout condition rapidly causes the filesystem to be lost and subsequently causes the device to enter a continual watchdog reboot cycle. This is only recoverable by using the command line tools to erase the filesystem and then reflash the firmware and download the main.py file.

    With our code built with version 1.18 operation under brownout condition is completely stable. The filesystem is never lost and we never encounter the continual watchdog reboot state.

    Something significant has changed in regards to handling the flash memory between versions 1.18 and 1.20 that has caused this. This renders 1.20 unusable for our purposes.

    Going forward we'll have to remain with version 1.18 until this issue is fixed.

    Thanks for your help and the useful links you provided.

    Cheers Scott.



  • Dear Scott,

    FatFS is known to corrupt the filesystem in brownout conditions [1], please use LittleFS. However, the LittleFS implementation of the official releases has some bugs, so we want to humbly direct you to our Squirrel firmware builds [2], which mitigate some important issues.

    Running that on our devices, we are pretty much satisified regarding overall runtime stability and robustness and have already been able to help others in this matter.

    Cheers,
    Andreas.

    [1] https://community.hiveeyes.org/t/fipy-verliert-programm-nach-power-off-durch-leeren-lipo-file-system-corruption-through-brownout-conditions/2057
    [2] https://community.hiveeyes.org/t/squirrel-firmware-for-pycom-esp32/2960


Log in to reply
 

Pycom on Twitter