earlephilhower / arduino-pico

Raspberry Pi Pico Arduino core, for all RP2040 and RP2350 boards
GNU Lesser General Public License v2.1
1.96k stars 406 forks source link

Flashing settings for Listfiles-USB - Docs #2118

Closed zjwhitehead closed 4 months ago

zjwhitehead commented 4 months ago

Thanks for what looks like a great library here https://github.com/earlephilhower/arduino-pico/pull/2028

I am flashing a Sparkfun promicro RP2040 and on MacOS and despite opening the Serial console etc it doesnt seem to work.

Could we get some more direction in the docs on what settings to use? I'm assuming:

Also an example sketch for how to read and write to the new FS could be great too. Thanks!

earlephilhower commented 4 months ago

Unfortunately I only have 2MB boards (genuine Picos) to work with so can't reproduce your specific issue. In general on the Picos it's just fire-and-forget. Pick a 1MB FS and run and things "just work." You could shrink to a 1MB FS, for testing, and see if there's some other limit I've missed. (I developed the FTL on 32-bit host systems with internal structures set up to support up to 16MB of flash, and it's gone through a bunch of FIO and valgrind testing, but maybe there's something onboard that's not captured that way).

I do/did host testing of the SPIFTL at 16MB (the max addressable flash size) but there may be some onboard issues at large spaces. What you can do is simply tell FAT to not use the FTL and run 4K raw sectors. You'll not get wear leveling, but there's a simple 1:1 mapping and no memory/performance overhead. See the docs for the config options, like so:

...
FatFSConfig c3;
c3.setUseFTL(false); // Directly access flash memory
FatFS.setConfig(c3);
//FatFS.format(); // Format using these settings, erasing everything
... start FatFS and FatFSUSB ...
zjwhitehead commented 4 months ago

Thanks! It looks like the sketch works on my Adafruit RP2040 Feather (8MB flash) so I'll do some more troubleshooting when I can. Eventually I get the sparkfun rp2040 working but Im wondering if it takes a long time to boot because calling FatFS.format() is really slow

earlephilhower commented 4 months ago

Ah, thanks for the update. There are some linear scans (to same RAM) which will take 8x as long on an 8MB FS as on a 1MB one so there may be some start-up latency, but it shouldn't hang, In any case, would you be able to try the non-FTL option above on the 16MB device and see if that succeeds? W/o an FTL the 16MB device should perform as fast as a 1MB one (but w/o any wear leveling).

One other thing could be the FatFS formatting. Maybe the larger FAT tables blow something up. In that case, the 4K sector size would reduce the # of sectors by 8x and hence do the FAT format faster...

earlephilhower commented 4 months ago

I just got a clone board from AX with 16MB of FLASH and was able to try both 8MB and 15MB filesystems. Using the example I was able to get both running without incident. The initial formatting was something like ~1.5 seconds/MB of FS and the restart time was ~ 0.5s/MB (i.e. the 15MB FS took ~20 seconds to do the initial formatting, but after that from the time I hit reset to the time it dumped the list was ~7 seconds).