Display the specific FS error using LED blink codes (with the correct branch)

[prochazkaml]

My Pico just kept blinking no matter what (tried flashing different firmware versions, erasing the "built-in" memory card file & replacing it with an empty one several times) and I wanted to know why it was failing, so I implemented simple blink error codes:

• 1 flash = FS mount error
• 2 flashes = Memory card file open error
• 3 flashes = Memory card file read error
• 4 flashes = Memory card file is empty
• 5 flashes = Memory card file contains data, but its size is incorrect

Turns out my Pico is failing with 4 flashes, so it cannot read the file properly as it thinks it contains 0 bytes. Not sure why that is happening, as the file I uploaded is exactly 131072 bytes (I used the empty memory card example which is provided in this repo).

I figured it might be useful to others for diagnosing such issues.

---

This is a follow-up to my previous pull request, where I unknowingly requested to push to the main branch instead of the development one. Also made a slight change to the commit by request, and added more error codes which may be useful.

[dangiu]

Thanks a lot for resubmitting! By the way I think I might know what is going on: my bet is that you forgot to perform safe ejection after copying the image. If you replug PicoMemcard into the PC after having copied the image is it still there with the same size? With the base version of PicoMemcard (no sd card) safe-ejection is needed to trigger the transfer to flash memory :)

[prochazkaml]

I use a script which I wrote some time back for copying files to flash drives, as Linux is especially terrible in this regard with caching (if you write only a small amount of data to the drive and then not umount it, it just writes nothing, as everything stays in the system's cache). The script even then mounts the drive again and performs an MD5 checksum on the copied file to check if everything went OK.

When I was uploading the memory card image to the Pico, this is what I got:

The MD5 checksum of the source file and the file from the Pico (which was checked after a full remount cycle) does match, so I don't know what's going on.

(yes, the script is called prusaload, as I originally only used it to send files to my 3D printer, but I now use it for everything 😁)

[dangiu]

I'm not too familiar with mounting/unmounting on linux, is it the same as safe ejection? Because the Pico needs to receive an SCSI stop command (with eject) in order to save the file to flash memory. Otherwise it's only kept in a virtual RAM disk. I've tested it on PopOS (based on Ubuntu 21.10) and it worked fine by pressing the safe eject button on the nautilus GUI. If nothing works try completly erasing the memory by flashing the appropriate binary found at the bottom of this page: https://www.raspberrypi.com/documentation/microcontrollers/raspberry-pi-pico.html And then re-flashing PicoMemcard :)

[prochazkaml]

Oh, well that makes sense, because even after the remount cycle, the file still remained in the Pico's RAM. I plugged the Pico in now, and the file is indeed only 0 bytes in size.

However, after checking the communication in WireShark, Linux clearly seems to send the required stop command when unmounting:

I've also tried nuking the Pico's flash (as you have suggested), but that did sadly not seem to help whatsoever.

However, I've now tried copying the file from my brother's Windows 10 PC, and that works fine, with the Pico's LED staying on after plugging it into the console. Well, I have some fixing to do on my computer.

There is also the nuclear option, which is to turn the PicoMemcard into a raw serial device and send the file over the serial port. Hopefully that won't be necessary.

[dangiu]

Weird indeed! Try on a different Linux installation, maybe even a live disk and see if it works. I tested it on different versions of both Ubuntu and Windows and I've not had any problems

[prochazkaml]

Thank you for the suggestion. I booted up a live install of Ubuntu inside of a VM, passed the Pico to it, copied the file using Nautilus, unmounted it using the GUI and the Pico then worked fine.

However, inside of the VM, if I would unmount the disk using "umount", it would fail, with the file remaining 0 bytes large. So it seems as if the Nautilus GUI (or possibly something else?) is doing some other magic than just unmounting the disk. I noticed that when I had unmounted the Pico using the GUI, it disappeared from the left panel, meanwhile running "umount" had no effect in this regard, the Pico still remained in the panel.

[prochazkaml]

Found it.

After unmounting the drive, I have to run sudo eject /dev/sdX1, where sdX is the block device assigned to my Pico. When I do that, the image is now properly preserved in the Pico's flash.

Thank you so much for your help! :)

[dangiu]

Awesome! No problem, I've learned something new today :)