Issue - stale code; updated files not being loaded properly

[gsboylan]

There was a thread on this topic on the archived OG forum: https://forum.micropython.org/viewtopic.php?t=8144

I have been experiencing exactly the same problem described in the old thread: when using rshell (or MicroPico) I occasionally encounter an issue where Micropython persists a stale set of code in flash. I haven't yet figured out what exactly puts Micropython into this bad state, but it happens to me pretty frequently.

I've hit this issue on several micropython ports (Pico, ESP8266, Sparkfun Pro Micro, and even a port I manually created and compiled for the eelectronicparts "Pico Mini" board) so I am reasonably certain that this is not an issue specific to any one port.

Copying new files over to the board does not actually result in the code being run. The filesystem explorer shows the new code (implying a successful copy) but changes are not reflected at runtime. Likewise, I can actually fully delete the files in rshell or Micropico, and they'll still be run on a reboot. Hard reboot/soft reboot/power cycle does not appear to matter, the issue persists.

Interestingly, after deleting the files from the filesystem they still show up in the output of os.listdir(). This implies to me that Micropython is caching a copy of the filesystem image somewhere and it's this cache that's persisting across reboots, not the filesystem itself.

Workarounds I have found:

• rename a file, upload it, and import it. This forces micropython to re-load the code and class definitions and overwrite the old ones. Afterwards, you can usually go back to the original name and micropython will load it properly until the next time this issue occurs.
  • e.g. Rename "main.py" to "moin.py" and upload it, enter the REPL, run import moin
• remove all the filesystem contents via os.remove() and os.rmdir() - this is the most consistent fix

[glenn20]

These kinds of issues can be very frustrating. The standard advice is to try transferring files onto the device with mpremote and see if you continue to have the same issues. mpremote is the tool that is supported by the core micropython team and I have found it to be very reliable when transferring files to/from micropython devices.

[peterhinch]

Are you issuing a reset (ctrl-d) between runs? The first time you run code after a reset it is compiled to bytecode, which lives in RAM. It will persist there until the next reset.

[gsboylan]

Are you issuing a reset (ctrl-d) between runs? The first time you run code after a reset it is compiled to bytecode, which lives in RAM. It will persist there until the next reset.

As mentioned in my post and in the original forum post, this issue is not limited to soft-resets. I can fully unplug the board, give it a couple minutes to discharge, and reconnect it and it'll still run the old code, hence why I think it's potentially an issue with something being cached to flash rather than just persisting in ram.

These kinds of issues can be very frustrating. The standard advice is to try transferring files onto the device with mpremote and see if you continue to have the same issues. mpremote is the tool that is supported by the core micropython team and I have found it to be very reliable when transferring files to/from micropython devices.

I haven't tried mpremote specifically yet, though I'll give it a shot next time I hit this issue. I'm skeptical since both of the other tools I've tried (rshell, micropico) do functionally the same thing by wrapping the serial REPL, but it's worth a shot.

[Josverl]

I have seen similar behaviour with PyMakr, where the root cause was an attempt of the sync/copy tool to prevent needing to copy files by caching state on the host, or in a semi-hidden file in the root of the flash.
Deleting that cache-file used to solve my problems.

Nowadays I just copy all that I need to the MCU using mpremote. Nite that mpremote uses a file hash to determine if a file actually need to be transferred, and theoretically that can go wrong, but I've not experienced that