Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MagTag filesystem wiped while trying to copy files. #3744

Closed
kattni opened this issue Nov 23, 2020 · 6 comments
Closed

MagTag filesystem wiped while trying to copy files. #3744

kattni opened this issue Nov 23, 2020 · 6 comments
Labels
bug crash espressif applies to multiple Espressif chips
Milestone

Comments

@kattni
Copy link

kattni commented Nov 23, 2020

Attempting to test this PR, which involves copying a folder containing images and a json file over to CIRCUITPY. Copy failed. When the board reset, the filesystem was wiped, everything returned to base state, including the Hello world! code.py. There were already two libraries and an updated code.py file on the board that were running before the filesystem was wiped.

@tannewt tannewt added bug crash espressif applies to multiple Espressif chips labels Nov 24, 2020
@tannewt tannewt added this to the 6.1.0 milestone Nov 24, 2020
@tannewt
Copy link
Member

tannewt commented Nov 24, 2020

You were using Mac OSX too right?

@kattni
Copy link
Author

kattni commented Nov 24, 2020

@tannewt Yes. 10.15.7.

@jepler
Copy link
Member

jepler commented Dec 1, 2020

I just had an event like this. Host is Linux. I had written out code.py and the last thing on the console was

Press any key to enter the REPL. Use CTRL-D to reload.soft reboot

Auto-reload is on. Simply save files over USB to run them or enter REPL to disable.
code.py output:
Traceback (most recent call last):
  File "code.py", line 29
SyntaxError: invalid syntax

The full backtrace of all threads in gdb said this

Thread 7 (Thread 1073734432):
#0  0x400324cd in xQueueGenericReceive (xQueue=0x3fffd56c, pvBuffer=0x3fffe2b0, xTicksToWait=<optimized out>, xJustPeeking=0) at ../../esp-idf/components/hal/esp32s2/include/hal/cpu_ll.h:33
#1  0x4015d384 in esp_event_loop_run (event_loop=0x3fffd550, ticks_to_run=4294967295) at ../../esp-idf/components/esp_event/esp_event.c:624
#2  0x4015d4f7 in esp_event_loop_run_task (args=0x3fffd550) at ../../esp-idf/components/esp_event/esp_event.c:115

Thread 6 (Thread 1073346136):
#0  0x400324cd in xQueueGenericReceive (xQueue=0x3ff9e5fc, pvBuffer=0x0, xTicksToWait=<optimized out>, xJustPeeking=0) at ../../esp-idf/components/hal/esp32s2/include/hal/cpu_ll.h:33
#1  0x400d8518 in timer_task (arg=<optimized out>) at ../../esp-idf/components/esp_timer/src/esp_timer.c:346

Thread 5 (Thread 1073598120):
#0  0x40031d5d in prvProcessTimerOrBlockTask (xListWasEmpty=<optimized out>, xNextExpireTime=0) at ../../esp-idf/components/hal/esp32s2/include/hal/cpu_ll.h:33
#1  prvTimerTask (pvParameters=<optimized out>) at ../../esp-idf/components/freertos/timers.c:544

Thread 4 (Thread 1073346540):
#0  0x400a5ac9 in tud_ready () at ../../lib/tinyusb/src/device/usbd.h:71
#1  serial_connected () at ../../supervisor/shared/serial.c:74
#2  0x4009e90f in run_code_py (safe_mode=NO_SAFE_MODE) at ../../main.c:339
#3  0x4009eaeb in main () at ../../main.c:514

Thread 3 (Thread 1073730372):
#0  sys_timeout_abs (abs_time=9878230, handler=0x400fc23c <lwip_cyclic_timer>, arg=0x3f0323a8 <lwip_cyclic_timers+8>) at ../../esp-idf/components/lwip/lwip/src/core/timeouts.c:199
#1  0x400fc262 in lwip_cyclic_timer (arg=0x3f0323a8 <lwip_cyclic_timers+8>) at ../../esp-idf/components/lwip/lwip/src/core/timeouts.c:260
#2  0x400fc37c in sys_check_timeouts () at ../../esp-idf/components/lwip/lwip/src/core/timeouts.c:400
#3  0x400f55c8 in tcpip_timeouts_mbox_fetch (mbox=<optimized out>, msg=<optimized out>) at ../../esp-idf/components/lwip/lwip/src/api/tcpip.c:104
#4  tcpip_thread (arg=<optimized out>) at ../../esp-idf/components/lwip/lwip/src/api/tcpip.c:148

Thread 2 (Thread 1073563588):
#0  vTaskDelay (xTicksToDelay=<optimized out>) at ../../esp-idf/components/freertos/tasks.c:1489
#1  0x4002b038 in spi_flash_os_yield (arg=0x3ffce830 <main_flash_arg>) at ../../esp-idf/components/spi_flash/spi_flash_os_func_app.c:107
#2  0x4002adc0 in esp_flash_erase_region (chip=<optimized out>, start=3215360, len=0) at ../../esp-idf/components/spi_flash/esp_flash_api.c:410
#3  0x400da01a in esp_partition_erase_range (partition=0x3fffc238, offset=0, size=4096) at ../../esp-idf/components/spi_flash/partition.c:422
#4  0x400a36c9 in supervisor_flash_write_blocks (src=0x3ffd2e14 <_mscd_buf> "CIRCUITPY  \b", lba=7, num_blocks=2) at supervisor/internal_flash.c:102
#5  0x4009f1c8 in flash_write_blocks (src=0x3ffd2e14 <_mscd_buf> "CIRCUITPY  \b", block_num=8, num_blocks=2) at ../../supervisor/shared/flash.c:130
#6  0x4009e2a0 in disk_write (pdrv=<optimized out>, buff=0x3ffd2e14 <_mscd_buf> "CIRCUITPY  \b", sector=8, count=2) at ../../extmod/vfs_fat_diskio.c:96
#7  0x400a5e91 in tud_msc_write10_cb (lun=<optimized out>, lba=8, offset=<optimized out>, buffer=0x3ffd2e14 <_mscd_buf> "CIRCUITPY  \b", bufsize=1024) at ../../supervisor/shared/usb/usb_msc_flash.c:160
#8  0x400a52c1 in mscd_xfer_cb (rhport=0 '\000', ep_addr=<optimized out>, event=<optimized out>, xferred_bytes=1024) at ../../lib/tinyusb/src/class/msc/msc_device.c:515
#9  0x400a4898 in tud_task () at ../../lib/tinyusb/src/device/usbd.c:520
#10 0x400a5b70 in usb_device_task (param=0x0) at supervisor/usb.c:68

.. it seemed like the USB thread which was trying to erase and rewrite flash was not able to make headway. However, as I have trouble debugging on the non-main thread I was not able to determine why it was not proceeding.

dhalbert pushed a commit that referenced this issue Dec 2, 2020
Otherwise we risk running code from flash while an erase is in
progress, crashing and corrupting the file system.

Related to #3744
@dhalbert
Copy link
Collaborator

@tannewt do you think this might be fixed?

@makermelissa
Copy link
Collaborator

I haven't experienced this since I was developing the MagTag library.

@tannewt
Copy link
Member

tannewt commented Dec 22, 2020

I think so. We can re-open if it crops up again.

@tannewt tannewt closed this as completed Dec 22, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug crash espressif applies to multiple Espressif chips
Projects
None yet
Development

No branches or pull requests

5 participants