docs: machine.RTC.memory examples not working
Documentation URL
https://docs.micropython.org/en/latest/library/machine.RTC.html#machine.RTC.memory
Description
Here is what the docs say about machine.RTC.memory:
RTC.memory(data) will write data to the RTC memory, where data is any object which supports the buffer protocol (including bytes, bytearray, memoryview and array.array). RTC.memory() reads RTC memory and returns a bytes object.
Having used that function several times on both the esp32-c3 and esp32-s2 (i believe the s3 too, but I'm not sure), I can tell you that following the examples to the letter will raise the following error : TypeError: function missing 1 required positional arguments. The missing argument is self, so the 2 ways I found to call the method is either machine.RTC.memory(machine.RTC(), b'data') or machine.RTC().memory(b'data'). I feel like the documentation should reflect that if the memory method is working as it should.
Code of Conduct
Yes, I agree
machine.RTC.memory undocumented and does not survive watchdog reset
The documentation for machine.RTC contains 7 methods, yet yet MicroPython v1.11-406-g4a6974bea on 2019-10-06; ESP32 module with ESP32 has only 3 methods: init(), datetime(), and memory().
I assume the memory() function is supposed to access some non-volatile storage.
>>> import machine;
>>> r = machine.RTC();
>>> r.memory("hi there")
Cntl-D soft reboot
[reset ensues]
>>> import machine;
>>> r = machine.RTC();
>>> print(machine.reset_cause(), r.memory())
5, b'hi there'
>>> machine.deepsleep(1000)
[reset ensues]
>>> import machine;
>>> r = machine.RTC();
>>> print(machine.reset_cause(), r.memory())
4, b'hi there'
>>> machine.WDT(0, 1000)
[reset ensues]
>>> import machine;
>>> r = machine.RTC();
>>> print(machine.reset_cause(), r.memory())
5, b''
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.