Skip to content

Pimoroni Pico 2 Plus: define TARGET_RP2040 missing and problem to upload data to flash using "Pico LittleFS Data Upload" #51

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

Closed
cledic opened this issue Sep 13, 2024 · 5 comments · Fixed by #52

Comments

@cledic
Copy link

cledic commented Sep 13, 2024

Hello to all,
I am using a Pimoroni Pico 2 Plus with the "GFX_Library_for_Arduino" library ver 1.4.9, but the "ImgViewerMjpeg_JPEGDEC" example compiles only by inserting the define: "TARGET_RP2040".

I then inserted the command "-DTARGET_RP2040" among the other defines in the board.txt file and the compilation ended successfully. I know that it is not a viable solution, but: can you suggest me how I can insert it correctly in compilation?

I have another problem: I can not upload the mjpeg files to flash.
I followed the instructions and installed the picolittlefs.JAR file. When I run the "Data Upload", the procedure does not complete, the UF2 volume window on my PC remains open, and the communication is interrupted: I am forced to do a RESET to the board. After the restart, the program cannot find the file.

I have tried both test programs for the LittleFS software: "FSUpload" and "SpeedTest", and they both work! It seems that the board's flash is working!

This is the console output when I start the file upload:
`
[LittleFS] data : C:\Users\me\Documents\Arduino\RP2350_ImgViewerMjpeg_ver0.01\data
[LittleFS] size : 4096KB
[LittleFS] page : 256
[LittleFS] block : 4096
/earth.mjpeg
/earth128.mjpeg
[LittleFS] upload : C:\Users\me\AppData\Local\Temp\arduino_build_857947/RP2350_ImgViewerMjpeg_ver0.01.mklittlefs.bin
[LittleFS] address : 281010176
[LittleFS] swerial : COM29
[LittleFS] python : C:\Users\me\AppData\Local\Arduino15\packages\rp2040\tools\pqt-python3\1.0.1-base-3a57aed\python3.exe
[LittleFS] uploader : C:\Users\me\AppData\Local\Arduino15\packages\rp2040\hardware\rp2040\4.0.2\tools\uf2conv.py

Resetting COM29
Converting to uf2, output size: 8388608, start address: 0x10bfe000
Scanning for RP2040 devices
Flashing D: (RP2350)
Wrote 8388608 bytes to D:/NEW.UF2
`
The volume window on my PC remains like this, open, and the board is locked:
pico_data_upload

How can I resolve this issue?

TIA
Best Regards
Clemente

@cledic cledic changed the title Pimoroni Pico 2 Plus: define TARGET_RP2040 missing and problem to download data to flash using "Pico LittleFS Data Upload" Pimoroni Pico 2 Plus: define TARGET_RP2040 missing and problem to upload data to flash using "Pico LittleFS Data Upload" Sep 13, 2024
@earlephilhower
Copy link
Owner

For the library issue, I suggest pinging the library author/repo. Pimoroni doesn't check here, AFAIK.

For the filesystem, that's actually a good thing I hadn't thought of and probably a real issue that may have drastic implications. I think it has to do with the faking (to enable their partitions, R5/ARM swapping, etc.) that the RP2350 ROM does vs. the RP2040 ROM.

On the RP2040 you make an ELF binary blob with a defined start address (FS_START) and then convert that to a UF2 file. UF2 files (from memory so don't exactly quote me) are straightforward and each 512 byte "sector" includes a start address + length for the block.

On the RP2040, if the UF2 file says "write 0xabcd @ 0x1010200" the RP2040 happily will erase 0x1010200 and write 0xabcd there without changing the data at all. So uploading a FS image is trivial. And when done w/the UF2 write the Pico automatically reboots.

On the RP2350, however, the boot ROM has a lot more intelligence and that UF2 image actually needs to be shifted out and a header prepended on the assumption that it's an executable image. So there's no longer a simple 1:1 mapping. We may need to use picotool to upload the FS, not copying a UF2, on the 2350. (Plus the Pico2 doesn't seem to reboot after this upload so maybe it's checking it for validity as a binary executable and throwing it away,).

In any case, though, the USB filesystem in your image is not real and just the emulated UF2 loader interface. Even when it works, you won't actually see your files there. It's just a figment of the Pico's imagination. :)

@earlephilhower
Copy link
Owner

Interesting note: The RP2040 BOOTROM documentation is ~30 pages and 1 section. The RP2350's is ~100 pages in 10 sections. Lots of goodness and power, but for low level users like this core it's almost like a whole new, incompatible OS/API to manage. 😢

@earlephilhower
Copy link
Owner

Quick testing from the command line shows that uf2conv.py + RP2350 BOOTROM can not upload a filesystem image to the RP2350. It seems to discard the binary image completely. Using picotool does succeed to write the raw data at the expected address, however. This is a plugin change and not core related (unless the plugin needs more info from the core to do its work...)

@earlephilhower earlephilhower transferred this issue from earlephilhower/arduino-pico Sep 13, 2024
@earlephilhower
Copy link
Owner

New commands to make a RP2350 bootrom compatible upload:

mklittlefs -c /home/earle/Arduino/data1/data -p 256 -b 4096 -s 262144 /tmp/tmp-608036-azMU6Jzqg2Bc-.littlefs.bin
picotool  uf2 convert /tmp/tmp-608036-azMU6Jzqg2Bc-.littlefs.bin -t bin tmp.uf2 -o 0x10fbe000 --family data
uf2conv.py --serial /dev/ttyACM1 --family RP2040 tmp.uf2 --deploy

earlephilhower added a commit that referenced this issue Sep 13, 2024
The RP2350 needs special UF2 processing to support a binary flash.  Adjust
the command lines depending on the build revision for the Pico core to accomodate.

Fixes #51
@earlephilhower
Copy link
Owner

I'm not going to be updating the JAVA 1.x plug in as the 1.x IDE is EOL and last updated around 3 years ago. If someone wants to backport this to the obsolete plugin, I'll be happy to look at PRs...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants