Double start of `code.py`

[UnexpectedMaker]

I'm experiencing a double start of "code.py" with beta 1 when powering the board from USB.

My APA cycles through a rainbow in code.py and I can see it goes from red to blue then turns off and then starts again at red.

This doesn't happen in beta 0 with the same code, and doesn't happen if I power the board from external 5V with no USB connected.

It also doesn't happen from a soft reset, so I suspect it's something to do with the mounting of the USB.

Update: Monitoring UART0 during the boot process shows nothing weird and no ESP32 specific restarts.

Build:Oct 25 2019
rst:0x1 (POWERON),boot:0x8 (SPI_FAST_FLASH_BOOT)
SPIWP:0xee
mode:DIO, clock div:2
load:0x3ffe6100,len:0x8
load:0x3ffe6108,len:0x18a0
load:0x4004c000,len:0x14b0
load:0x40050000,len:0x2134
entry 0x4004c2cc```

[tannewt]

This can happen when your OS writes to the device. We did update the USB stack so it may be working better. Why do you think this is an issue?

[UnexpectedMaker]

I think it's an issue because it happens every time I plug the device in, not just the first time, and it never happened before beta 1. Not in beta 0 or any build prior to that. So it's new to beta 1.

If it's the expected behaviour why has it only started in beta 1?

[tannewt]

Ok, will take a look to see if it's as expected.

[UnexpectedMaker]

Update: Testing this morning on latest as of today, I can confirm that:

• Re-start code.py issue still exists - but it seems to only happen with the flash size is set to 16MB
• Switch from 16MB to 4MB stops the restart. Switching back to 16MB introduces it again
• Switching between DIO/QIO makes no difference

[tannewt]

Could you add a print here: https://github.com/adafruit/circuitpython/blob/main/supervisor/shared/autoreload.c#L79

Then you'll be able to see when writes to the USB occur. The new behavior sounds more correct because any Host OS write will cause a reload.

The other thing to check is the behavior of it with a Linux and Windows computer.

[UnexpectedMaker]

Sure, Where does print output to?

[tannewt]

I usually use ESP_LOG to print which goes out the UART.

[tannewt]

I tried the latest code on my prerelease UM Feather S2. Autoreload works as I would expect. It starts code.py on power up and then on mount when my Linux OS writes to it.

I'm not sure why Beta 0 didn't do this when it should have. Regardless, it works now.

[UnexpectedMaker]

So this is the correct behaviour? Can't be. As it doesn't do it when I use smaller Flash size of 4MB. Only when I use 16MB.

[tannewt]

Reloading at any point after mount is totally acceptable because the Host OS may choose to write the disk at any point. The smaller flash sizes may be treated differently by the host OS.

If it were a CircuitPython bug I'd expect it to happen regardless of USB being connected.

[microdev1]

I formatted the CIRCUITPY drive with windows formatting utility and it fixed double auto-reload. This must be something to do with how we set-up the file system which might be different for a large user_fs.

_Tested this on microS2 with 12MB partition size._

[skieast]

I also tried different formats with different allocation units (FAT16/4096, FAT32/8192) and did not see any change after formatting on a windows machine and then trying the board on a macos machine (Big Sur Preview and Catalina). This was with a Stetelthings Maia board, modified by replacing the spi flash with 16MB.

I might look more closely at the mac and see why it tries to write but I cant really see the issue. As someone said its something to do with the volume size. Perhaps APFS, as the minimum APFS container size is #define NX_MINIMUM_CONTAINER_SIZE 1048576. As the volume size on the 4MB flash is 940 KB we are below that. All speculation here.

[microdev1]

I formatted the CIRCUITPY drive with windows formatting utility and it fixed double auto-reload.

This issue still exists and the above fix still applies. I used a windows machine to format the drive.

I logged the time between subsequent calls to autoreload_trigger, most calls are within 100ms but the third last call differs by:

• Just Ctrl+S with the file open and no changes: ~940ms
• Adding new data in the file and then saving: ~1080ms
• Removing everything in the file and then saving: ~1280ms

[dhalbert]

May have been fixed by #7845, so let's re-test.