Old files persisting/will not delete

General discussions and questions abound development of code with MicroPython that is not hardware specific.
Target audience: MicroPython Users.
Post Reply
supersquirel500
Posts: 2
Joined: Fri Apr 10, 2020 3:05 am

Old files persisting/will not delete

Post by supersquirel500 » Fri Apr 10, 2020 3:34 am

I have an issue regarding micropython file storage in flash. Using for a senior design project and has come a long way in development. The leadup to the issue is this:

1) Current micropython did not support RTC watchdog timer reset, so I wrote one myself in C, compiled the firmware, flashed, and used the module for awhile.

2) After this one of our files in our codebase contained a line to import the module: "import rtcwatchdog"

3) Due to persistent issues with mbedtls_ssl errors arising from ussl.wrap_socket I have decided to roll back this custom module addition and flash the unmodded micropython I pulled and compiled from the official GitHub today thinking maybe modding the firmware may have generated these issues (maybe...). I wiped flash in the process on putting the new firmware on.

4) ampy'd all used files back onto the board and ran. Oops forgot to remove the line "import rtcwatchdog" since I got rid of that module.

5) changed the code, ampy it back over.

6) Errors out when doing initial imports. Says it can't import rtcwatchdog. Huh? That line isn't there anymore in the code I gave you, how do you even know the name of the module? Maybe its persistent in memory or something.

7) import os and use os.remove('gdt.py') as this is the file that USED to have "import rtcwatchdog" but I removed it. Okay file completely gone. (or so it says). I power cycle the board too just to be sure RAM gets cleared.

8) ampy gdt.py back over and what the heck it still sees a nonexistent line thinking I told it to import rtcwatchdog.

I've tried erasing flash then reflashing the board,
power cycling the board to make sure RAM gets cleared
deleting the file via os.remove('gdt.py')
The file I am giving it does not contain the string "rtcwatchdog" at all. I'm not even sure how it even knows that. I'm at a loss here.

Using ESP32-PICOKITd4

Will keep trying but I appreciate any insight

User avatar
jimmo
Posts: 2754
Joined: Tue Aug 08, 2017 1:57 am
Location: Sydney, Australia
Contact:

Re: Old files persisting/will not delete

Post by jimmo » Tue Apr 14, 2020 4:15 am

Hi,

Sounds like you've done all the right things!

The only other things I can suggest is:
- Try importing that module after removing the file from the filesystem (using os.remove and a soft reset). Maybe it's a frozen module by accident?
- Try doing print(open('gdt.py', 'r').read()) just to confirm that the file on the filesystem really dones't contain that line.

zed
Posts: 2
Joined: Thu Jul 22, 2021 1:23 am

Re: Old files persisting/will not delete

Post by zed » Thu Jul 22, 2021 1:29 am

Hi,
I have had the exact same issue for 2 days.
Changing code in one of the class was not fixing my issue. Pulled my hair trying to find what was wrong with my code, double checked on the file system with edit that my code was actually on the board, which it was...
Eventually renamed the class in the module to as a desparate attempt to fix my issue, to find out that I now have a importerror for the new name, even though the name is changed in the file.

Just like you did, I flashed the image (1.13) again, flashed the latest image 1.16 again, power cycled the board to clear RAM. Nothing worked.
Eventually I stopped resisting to rename the file and "force" MPY to look inside a new non-existing file, and it worked.

Problem solved, but I am frustrated that this can even be an issue. Using D1 mini pro, the problematic class was inside a folder, if it makes a difference.
I created an account on the forum just to up your issue that still exists.

User avatar
jimmo
Posts: 2754
Joined: Tue Aug 08, 2017 1:57 am
Location: Sydney, Australia
Contact:

Re: Old files persisting/will not delete

Post by jimmo » Thu Jul 22, 2021 4:13 am

zed wrote:
Thu Jul 22, 2021 1:29 am
Problem solved, but I am frustrated that this can even be an issue. Using D1 mini pro, the problematic class was inside a folder, if it makes a difference.
I created an account on the forum just to up your issue that still exists.
Thanks for reporting. I'd really like to get to the bottom of this issue, I have heard other people report something similar. I have never seen this myself, despite using MicroPython almost every day.

So just to be really clear the issue you're seeing is:
- Using D1 Mini Pro (that's ESP8266 right)
- Module has not been imported since boot (or last soft-reset) -- import sys; print(sys.modules)
- Filesystem definitely contains the new code -- print(open('dir/foo.py', 'r').read()) )
- "from dir import foo" (or import dir.foo) does something different (i.e. old code), but print(foo.__file__) gives the correct path
- Renaming foo.py to bar.py, then "from dir import bar" gives the correct behavior.

zed
Posts: 2
Joined: Thu Jul 22, 2021 1:23 am

Re: Old files persisting/will not delete

Post by zed » Thu Jul 22, 2021 7:38 pm

Thanks jimmo.
I don't have the problem anymore but will report back if I come across it again.
jimmo wrote:
Thu Jul 22, 2021 4:13 am
- Using D1 Mini Pro (that's ESP8266 right)
Correct
jimmo wrote:
Thu Jul 22, 2021 4:13 am
- Module has not been imported since boot (or last soft-reset) -- import sys; print(sys.modules)
Not verified this way, the code would start right away in main and crash while trying to import the new class name. main.py was therefore using the new import directive, while the foo.py file was not updated with the new Class name, even though the filesystem would show foo.py with the right Class name for the import directive (point below)
jimmo wrote:
Thu Jul 22, 2021 4:13 am
- Filesystem definitely contains the new code -- print(open('dir/foo.py', 'r').read()) )
Verified via rshell edit function but not within MPY itself.
jimmo wrote:
Thu Jul 22, 2021 4:13 am
- "from dir import foo" (or import dir.foo) does something different (i.e. old code), but print(foo.__file__) gives the correct path
First part correct, print(foo.__file__) not tested
jimmo wrote:
Thu Jul 22, 2021 4:13 am
- Renaming foo.py to bar.py, then "from dir import bar" gives the correct behavior.
Correct. Imported the class using "from dir.foo import Class" and then "from dir.bar import Class" to fix the issue, same Class name

Post Reply