Custom RP2040 UF2 Issues

[CoffeePlusPi]

I never did it because i figured if the board won’t load the pico UF2 it won’t load this

No it should work even if the Pico cannot access Flash, has no Flash.

If your board is presenting the MSD BOOTSEL drive you should be able to upload a Run from RAM program which it will write to RAM while completely ignoring the Flash. Once uploaded it should immediately reboot, jump straight into RAM, begin executing the code without trying to access Flash, and that should also run without accessing Flash.

If the Run from RAM code executes, shows the expected output when 'minicom -D /dev/ttyACM0' is launched, it would suggest everything is working except for access to the Flash.

If the Run from RAM doesn't work I haven't correctly understood the Boot ROM code flow or there are other issues which might need investigating.

Yeah I can’t imagine any major flaws in the board, I think it could just be a RAM issue; although I noticed a difference between my board and the minimal example from raspberry pi (the board I followed). That being what looked like power lines from the USB port were quite thicker compared to my board, so would low voltage cause an issue with flash?

[arg001]

Yeah I can’t imagine any major flaws in the board, I think it could just be a RAM issue; although I noticed a difference between my board and the minimal example from raspberry pi (the board I followed). That being what looked like power lines from the USB port were quite thicker compared to my board, so would low voltage cause an issue with flash?

Thickness of the lines from the USB port to the 3V3 regulator chip is unlikely to be an issue, as there's already significant resistance in the cables etc.

However, bad power distribution after the regulator can cause significant issues - at least one previous poster had a board with bad layout which would just about run in the bootloader (which runs at low CPU speed), but as soon as it started running real code and stepped up the speed it crashed.

If you want us to review your layout, post images of the PCB layers (don't just post CAD data - that takes more work for people to load it up and view it).

[CoffeePlusPi]

So I am trying to run this Run from RAM file from my pi 4 to the board I made. I use VSCode for this, and the CMakeLists.txt file is giving some errors on lines 4 and 6. Those errors regarding no command "pico_sdk_init()" and it could not load /external/pico_sdk_import.cmake. Here is the code:

set(PROJECT run_in_ram)
cmake_minimum_required(VERSION 3.12)
set(PICO_SDK_PATH $ENV{/home/pi/pico-sdk})
include(${PICO_SDK_PATH}/external/pico_sdk_import.cmake)
project(${PROJECT} C CXX)
pico_sdk_init()
add_executable(${PROJECT} main.c)
target_link_libraries(${PROJECT} pico_stdlib)
pico_add_extra_outputs(${PROJECT})
pico_enable_stdio_usb(${PROJECT} 1)
pico_enable_stdio_uart(${PROJECT} 0)
pico_set_binary_type(${PROJECT} no_flash)

[hippy]

The issue is in line 3 -

• set(PICO_SDK_PATH $ENV{/home/pi/pico-sdk})

That should ideally be -

• set(PICO_SDK_PATH $ENV{PICO_SDK_PATH})

But, if you haven't set the PICO_SDK_PATH environment variable, you can use -

• set(PICO_SDK_PATH /home/pi/pico-sdk)

Though, if you have installed in a '~/pico' sub-directory, I would have expected -

• set(PICO_SDK_PATH /home/pi/pico/pico-sdk)

[CoffeePlusPi]

An aside : Your "12 mm button" on your schematic doesn't make a whole lot of sense.

I am guessing it's relying on having leg 1 and 3, plus leg 2 and 4, shorted internally. Is it really a normally closed button, push to make open circuit ?

I would also have expected to see some resistors for GPIO27_ADC1 to prevent shorting whatever supplies a voltage to ADC1, or GPIO27, having its output shorted to 0V/GND which probably won't be good for its health -

Code: Select all

            |    ___           ___
GPIO27_ADC1 |---|___|---.-----|___|---O GPIO27 / ADC1
            |           |
            |           O |_
            |             |_|
            |           O |
            |           |
         0V |-----------^-------------O 0V
            |

I couldn't see anything otherwise wrong with the circuit. I'd be suspecting broken track, solder splash, or track routing error on the PCB. Is the Flash chip fitted the right way round ?

I also took a notice to this comment “is the flash chip fitted the right way round”. Quite honestly, I believe it is, when I got my pcb made it was no question on the flash and it seemed as if it was placed correctly, though I can look into this more. I don’t think it’s placed incorrectly though.

[CoffeePlusPi]

Hey everyone, I wanna start off saying that I have not been working on this project back-to-back, it’s a project that I wanted to do and I unfortunately have to solve its flaws (yay engineering!). I’ve done some testing on the board and I found out I had to remove my 10K Ω resistor on the DNF R2, which changed nothing, I also learned that the only files on the board (including invisible ones) are from the boot loader section. Any UF2s I drop in sit for a few seconds invisible, then the board ejects and remounts as usb again. I did however notice that .py files will sit on the board visibly in Finder (I use Mac) until the board is ejected and remounted.

I tried using the Run from RAM code, but no matter what I tried, VSCode won’t import the pico sdk and it gives me an error from it, so I’m working on getting my Windows 10 machine set back up. I also fetched my board file/layout, and I can drop the images of its layers here. Thanks so much for your help and patience, I haven’t done anything with developing a RP2040 board and had a different sight in mind.

[CoffeePlusPi]

I grabbed the images of the layers F.cu and B.cu and Silkscreen. If you need other layers just ask!

[arg001]

Is this a 4-layer board with groundplane on one of the internal layers? There's too little GND connectivity for it to work as a 2-layer.

[CoffeePlusPi]

No this is a 2 layer board per the minimal design of raspberry pi.

[arg001]

OK, on closer inspection it's not as bad as it looked (something odd with the ground fill on the bottom side around the CPU, but it does in fact touch some of the via holes up to the CPU belly pad). Xtal and decoupling capacitors are further away from the CPU than ideal, but not necessarily enough to cause trouble.

Your USB-C connector wiring looks odd: most USB-C connectors need you to wire the D+ and D- each to two pins to support the reversal function; likewise there's usually two pins for each of VBUS and GND. Possible you've picked a connector that makes these links internally, but most require you to do it on the PCB. Still, that's not your current problem.

Layout around the 3V3 regulator is bizarre - why that Y-shaped arrangement rather than just linking the two Vout pads directly? And thicker tracks would be better.

But none of this seems like a clear cause of your current problem.

[CoffeePlusPi]

Definitely interesting, I tried working off of the minimal design from raspberry pi and making changes to accommodate for the USB-C, which does explain why reversibility doesn’t work, but I don’t mind; although in the minimal design example, raspberry pi did have that little Y shape around the 3v3 pins.

[CoffeePlusPi]

Hi guys,

I did more tinkering with my board, because I am determined to see an LED blink. I said before that the board stores files in USB mode, but they are made invisible, and I was partially correct. The invisible files include the bootloader and all that which we are aware of, but I also said things like UF2s stayed there, which I was incorrect in saying that, the storage I saw taken up was the bootloader’s invisible files. I’m not sure if this information is helpful in any way, but I feel like it could stop me from doing anything code wise since we now know the board doesn’t retain files, and that maybe there is in fact a hardware issue; hopefully it’s a fixable one I can do with the current board. If not, I make another board I guess.

[arg001]

I said before that the board stores files in USB mode, but they are made invisible, and I was partially correct. The invisible files include the bootloader and all that which we are aware of, but I also said things like UF2s stayed there, which I was incorrect in saying that, the storage I saw taken up was the bootloader’s invisible files

This is all meaningless: the emulated USB drive isn't supposed to retain files, and if it ever does then that's just caching effects by the OS on the host PC. Note that this whole UF2 mechanism was invented by Microsoft, and it's an enormous kludge, so it's not surprising if the behaviour on Mac shows up some of the rough edges.

What's actually going on here is that the target device isn't actually a writeable piece of USB mass storage at all. It presents as USB mass storage, but always returns fixed contents if the host reads sectors from it - in the RP2040 case, the hard-wired welcome.html etc. If the host tries writing to the mass storage, it appears as if the data is just thrown away - reading the same sectors back again will show them unchanged. How the UF2 mechanism works is that it assumes when you ask the host to copy a .UF2 file onto the USB mass storage, you don't know exactly how the host OS will choose to lay out the file onto the (fake) disc blocks of the USB storage, but you can assume that the OS will write all of the data in the UF2 file to disc blocks somewhere on the emulated USB drive. So the UF2 file is broken down into small chunks assumed to fit in a disc block, and each chunk can be processed independently (and has redundant data identifying it as UF2). As the host OS writes each chunk onto the USB storage, the RP2040 ignores where the host has asked for it to be written, but before throwing it away checks for the UF2 format and if so actions the instructions in there (typically to write some data to the RP2040 flash). This is why UF2 files are much bigger than the original binary: each chunk of 256 bytes is accompanied by 256 bytes of control data.

You can read the spec here: https://github.com/microsoft/uf2
In my opinion, it's really horrible - but in raspberry pi's defence, they didn't invent it!

Anyhow, the bottom line is that reading via the USB mass storage interface is never going to tell you anything about what is currently on the RP2040 flash. Any appearance that it has retained data is just an artifact of the host OS.

If you are able to run the 'picotool' utility instead, this talks directly to the RP2040 bootrom with a sensible 2-way protocol and this can read out what is currently in the flash.

[hippy]

Note that this whole UF2 mechanism was invented by Microsoft, and it's an enormous kludge
In my opinion, it's really horrible - but in raspberry pi's defence, they didn't invent it!

I think the concept of UF2 files themelves is quite elegant, just an evolution of S-Record, Intel Hex, DFU files et al, with some optional bells and whistles added.

Most issue I would say arise in implementing the functionality of any bootloader and virtual file system to accept drag-and-drop UF2 files and Microsoft have no say or control over that.

[CoffeePlusPi]

Is it possible that the bootrom on both my rp2040 boards are bad?

[trejan]

Is it possible that the bootrom on both my rp2040 boards are bad?

Highly unlikely

[CoffeePlusPi]

Ok that’s good, what about enabling UARTS or one of the UART to usb/serial adapters. I’ve seen them around and some people have had to enable the UARTS to upload things.

[arg001]

Note that this whole UF2 mechanism was invented by Microsoft, and it's an enormous kludge
In my opinion, it's really horrible - but in raspberry pi's defence, they didn't invent it!

I think the concept of UF2 files themelves is quite elegant, just an evolution of S-Record, Intel Hex, DFU files et al, with some optional bells and whistles added.

Some aspects of the format (those extra bells and whistles), I could agree with you. Purely viewed as a file format it's quite nice, albeit a little inefficient in file size (maybe unimportant if you later compress it).

But the whole purpose of it is to support the drag-and drop aspect.

Most issue I would say arise in implementing the functionality of any bootloader and virtual file system to accept drag-and-drop UF2 files and Microsoft have no say or control over that.

But they invented this format precisely for the purpose of enabling use with this kludge of a non-filesystem, relying on host PC OS having benign behaviour to a USB mass storage device which behaves badly (doesn't preserve the contents of sectors written to it). This has already lead to trouble - there was a beta of some MacOS version that wouldn't work with RP2040; Apple fixed it, but it wasn't really their bug in the first place.

This isn't buggy behaviour of the RP2040 bootrom, it's the bootrom doing exactly what the UF2 authors expect of it, which works in practice most of the time but isn't guaranteed to do so and causes confusion when people see it not behaving as expected.

[arg001]

Is it possible that the bootrom on both my rp2040 boards are bad?

No, the bootrom is quite clearly working as expected on your boards. Now your flash chips could in principle be bad, but seems unlikely.

I repeat my recommendation to try with Picotool to see if you can read/write the flash: doing so via drag-and-drop gives you no diagnostics at all when it doesn't work.

[CoffeePlusPi]

Hey everyone,

I bought USB to UART adapters for the board I made, and I tested by starting on a pico, and can happily confirm that I can write to both my board and the pico. However, my board still ejects and remounts, and same goes for the pico except the pico doesn’t remount. The adapters are successfully able to write to my board and give it a com port though , so that’s nice. Any other ideas for why my board ejects and remounts though? I tried running hello world codes that print using the serial monitor and while the pico could print, my board kept remounting and ejecting.

[CoffeePlusPi]

So I also forgot to place a 3v3 GPIO on the board

This of course makes the process harder since I need those 3 volts running to the adapter. I already tested without 3v running to the adapter when using the pico and it didn’t work, it only worked when 3v was supplied to the adapter from the pico. Ideas? Like I said I forgot to add that GPIO to my board so no matter how good the wire is it won’t change unless it has that 3 volts.

[CoffeePlusPi]

Hi guys,

I reworked a 3v3 GPIO into my board through another part of the board and that works now, but I still have the issue where the board constantly goes into boot select. I tried running picotool and it could find my device and all that but it says Program Information: None. I tried running the load function and once my file was loaded I rebooted the device (using picotool). So now we are almost back to square one, board keeps going into boot select, no files will load onto it, although this time I have a com port, bcuz I got the UART to USB adapter working properly.

(I tried loading a program through the Arduino ide and seeing if that pops up too but it didn’t)

[CoffeePlusPi]

Hey guys,

I figured it out. After this 4 month quest, I found that there was a 3 volt via touching ground, grounding the flash chip and preventing it from receiving power. I scratched that trace, rerouted with some wire to 3v3, and the board works like a charm. It has a serial port and I can upload code like it’s a pico. Gotta thank you guys for giving the feedback I got, I’m certainly gonna apply it when I reattempt the board. It’s been helpful chatting and I feel I learned something. Thanks again.

[hippy]

The first reply suggested checking for exactly that and many other posts pointed to it being a hardware issue. Not sure how a 3V3 touching 0V allowed it to operate at all but glad you got there in the end.