RP2040 Pico - storage.erase_filesystem() does not reformat and erase

[braingram]

Board: RP2040 Pico
Firmware: 6.2.0 beta and 20210126-a2ac2da build
OS: Ubuntu 20.04.1 LTS

The drive appears almost full but the files do not add up to used space. Reloading the uf2 file doesn't change the filesystem contents (I'm not sure if this should). Running "storage.erase_filesystem()" in the REPL causes the board to unmount (presumable reset) but does not auto re-mount. When unplugged and plugged back in the filesystem contents appear unchanged.

Here's output of df -h:

brett@panini:/media/brett$ df -h /media/brett/CIRCUITPY/
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdb1      1004K 1001K  3.0K 100% /media/brett/CIRCUITPY

and ls -la:

brett@panini:/media/brett$ ls -la /media/brett/CIRCUITPY/
total 21
drwxr-xr-x  2 brett brett 16384 Dec 31  1969 .
drwxr-x---+ 3 root  root   4096 Jan 25 19:40 ..
-rw-r--r--  1 brett brett    96 Sep  1  2016 boot_out.txt
-rw-r--r--  1 brett brett    15 Jan 25 19:29 code.py
-rw-r--r--  1 brett brett     0 Jan 25 19:29 .code.py.swp

[braingram]

It appears that running the 'nuke' example from the pico-sdk fixed this issue: https://github.com/raspberrypi/pico-examples/tree/master/flash/nuke

brett@panini:/media/brett$ df -h /media/brett/CIRCUITPY/
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdb1      1004K  2.0K 1002K   1% /media/brett/CIRCUITPY

The bad thing is this may have erased any evidence of a bug but I'm happy to try and reproduce it if it would be helpful.

[tannewt]

Thanks for the issue! It appears erase_filesystem may not be working.

[dhalbert]

I copied some larger audio files to CIRCUITPY, using up about 30% of the space. storage.erase_filesystem() reset the board but did not reformat the filesystem. The filesystem appears the same before and after. So perhaps the original issue was a corrupted filesystem that wasn't cleaned up by erase_filesystem(). I've changed the title to reflect the more general issue.

And, as noted, after the reset, CIRCUITPY does not remount automatically.

[jepler]

I have also reproduced this behavior.

[jepler]

I ran storage.erase_filesystem() in the repl, then got a traceback in gdb using a picoprobe.

The debugger shows that this is down in the USB device enumeration workaround code. The "tight loop" never terminates.

^Ctarget halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x00000178 msp: 0x20041f00

Thread 1 received signal SIGINT, Interrupt.
hw_line_state ()
    at sdk/src/rp2_common/pico_fix/rp2040_usb_device_enumeration/rp2040_usb_device_enumeration.c:54
54	    while (hw_line_state() == LS_SE0) tight_loop_contents();
(gdb) where
#0  hw_line_state ()
    at sdk/src/rp2_common/pico_fix/rp2040_usb_device_enumeration/rp2040_usb_device_enumeration.c:54
#1  hw_enumeration_fix_busy_wait_se0 ()
    at sdk/src/rp2_common/pico_fix/rp2040_usb_device_enumeration/rp2040_usb_device_enumeration.c:54
#2  hw_enumeration_fix_wait_se0 ()
    at sdk/src/rp2_common/pico_fix/rp2040_usb_device_enumeration/rp2040_usb_device_enumeration.c:71
#3  rp2040_usb_device_enumeration_fix ()
    at sdk/src/rp2_common/pico_fix/rp2040_usb_device_enumeration/rp2040_usb_device_enumeration.c:34
#4  0x10038e06 in dcd_rp2040_irq ()
    at ../../lib/tinyusb/src/portable/raspberrypi/rp2040/dcd_rp2040.c:328
#5  0x200007d4 in irq_handler_chain_slots ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) finish
Run till exit from #0  hw_line_state ()
    at sdk/src/rp2_common/pico_fix/rp2040_usb_device_enumeration/rp2040_usb_device_enumeration.c:54

The stack of CircuitPython can't be seen, but I verified that if all the lines except usb_disconnect() in common_hal_storage_erase_filesystem are commented out, the problem still occurs, so it looks like this has to do with USB and not storage.

[jepler]

@hathach if you have a chance can you look at this? As usual, CircuitPython is behind, but I tried with tinyusb at master and it was the same.

[tannewt]

@jepler If you pick this up again I'd recommend reading the interrupt state of the USB peripheral. There may be an interrupt occurring that the irq handler fails to handle leading to an infinite irq loop.

[hathach]

hmm, I put the tud_disconnect() to my example with pretty the same code, and it could reset and re-mount just fine. I dived into the dcd driver, and it seems to behave correctly within my simple example. However, in cpy, it stucks as jepler said. 🤔 🤔 and 🔍 🔍

[hathach]

thanks @jepler gdb trace, I have ound the issue. After tud_disconnect() is called:

1. pull-up register is disabled and
2. device got both Bus Reset (SE0 > 2.5 us) and Disconnection event (SE0 > 2us)

The difference between my example (and other pico-sdk example) and circuipython is cpy disable the alarm pool feature PICO_TIME_DEFAULT_ALARM_POOL_DISABLED=0

https://github.com/raspberrypi/pico-sdk/blob/master/src/rp2_common/pico_fix/rp2040_usb_device_enumeration/rp2040_usb_device_enumeration.c#L61

which cause walkaround with the to use the alternative blocking wait while SE0 on the bus. Unfortunately unlike enumeration, (where host will de-assert bus reset), this is permanent SE0. I will do a bit more read up and will try to fix it within rp2040 later on. posting issue to pico-sdk as well if needed.

[tannewt]

@hathach We might be able to turn the alarm pool on. I didn't put a lot of thought into how we're using the SDK's timing. I was mainly trying to avoid the SDK doing any allocations because we're using all of RAM ourselves.