Repository navigation
machine.RTC.memory undocumented and does not survive watchdog reset #5199
Description
Activity
I think this is causing your problem
https://github.com/espressif/esp-idf/blob/master/components/esp32/cpu_start.c#L159
The RTC.memory also gets cleared when the brownout detector was triggered (which also results in a machine.reset_cause() == 5 == machine.SOFT_RESET).
This means I can't use it to count the brownout resets. Sometimes my ESP32 boards get into a state where their voltage regulators seem to get tired and there is a brownout reset every time it boots and executes
network.WLAN.activate(1). This means it can sit in this loop repeatedly for hours until there is a lucky moment when it comes alive and can make a connection out.I have seen this repeated brownout on WLAN.activate behavior when connected (and powered) from a laptop USB so I can read the serial line. But obviously when I wire it up to its own power supply and it goes into a locked room I can't be sure this is what's happening when it goes off-line for 6 hours a week later. However, if when it came online it reported to me that it had experienced 4000 brownouts in a row, then knowing that each brownout-reboot-brownout cycle took 5 seconds, I'd have a provable diagnosis.
There is already a magic number in there which is checked. It shouldn't need to be cleared down unless the magic number is invalid imho.
@goatchurchprime did you look into whether the brownout trigger levels are configurable?
Interesting - can you try this @goatchurchprime and let me know
https://arduino.stackexchange.com/questions/55702/esp32-disable-brownout-detector
ESP32 boards get into a state where their voltage regulators seem to get tired and there is a brownout reset every time it boots
In the interests of reliability I'd want to know the (electrical) cause of this. Could the regulator be overheating and shutting down until it has cooled? Is the behaviour dependent on the voltage powering the device?
Me too. The it stopped doing it once I took it down out of the ceiling where it was running a dotmatrix sign and left it on my desk for a day. These long-delayed hardware issues are a real headache.
What would help a lot, as well as being able to distinguish and count brownouts, would be a register that stored the time.ticks_ms() value from before the last reset so one could tell where in the bootup process it all went wrong.
Should be trivial to patch the code.
Your problem is your beta test environment is significantly different from your alpha (bench) test environment which is slowing down your iterations to fix this.
I don’t mind doing the work and submitting a PR but I don’t want to waste my time if it’s not accepted.
What’s the view from the maintainers on removing the wake reason check and leaving it to the magic number?
Test build generic ESP32 binary here to try
https://github.com/DynamicDevices/micropython/releases/tag/v1.11-rtcbss
- added 2 commits that reference this issue
on May 23, 2021 - added a commit that references this issue
on Nov 16, 2021 - added a commit that references this issue
on Apr 11, 2023 (Just to summarise the status, particularly for @dpgeorge, since it's been a while!)
This ticket covers a couple of issues that are required to make
machine.RTC().memory()usable for the esp32 port. Namely:memory()is not documented- The memory is not always preserved, particularly over watchdog resets
If #6713 can be tidied up it looks appropriate to resolve 1. #7298 appears to resolve 2.
It would be good to sort these out soon.
Also, tangentially related, #7133 provides
RTC().usermem()that allowsctypestructures to be easily stored in RTC memory. I think it can be considered separate to 1 & 2 above, though there is some cross-over.Finally, esp32/esp8266 are currently the only ports that supports
RTC().memory()- other ports could provide it. And there are inconsistencies across ports with the otherRTC()methods (especiallyalarm,canceletc). I'll raise a separate ticket that summarises these widermachine.RTC()issues.I now see documentation for RTC.memory at https://docs.micropython.org/en/latest/library/machine.RTC.html#machine.RTC.memory
and #7298 has been merged - and released as part of 1.22.0
Commit 78b3fe5Proposing to close this. CC @mattytrentini
Reacted by Matt Trentini and Volodymyr Shymanskyy
The documentation for machine.RTC contains 7 methods, yet yet
MicroPython v1.11-406-g4a6974bea on 2019-10-06; ESP32 module with ESP32has only 3 methods: init(), datetime(), and memory().I assume the memory() function is supposed to access some non-volatile storage.
Calling
machine.reset()also wipes this RTK.memory storage.I guess we've found a way to tell the difference between the Ctrl-D soft reboot and a watchdog reset, outlined in issue #5134 (since the latter disappears the memory), but it's not quite what I want.
The use of this storage is to enable some form of debugging wherein the code keeps updating where it is in the various suspect loops and functions, so that when the watchdog resets it you have a hope of finding out where it hung.