Custom RP2040 UF2 Issues

[CoffeePlusPi]

Hi!

So I made this custom board utilizing an RP2040. I followed the minimal design example and my boards came pre assembled with the bootloader loaded. I tried flashing the Pico UF2 file and it kept remounting as RPI-RP2 even if I didn’t hold the 2 J2 pins together. I have checked my connections and also tied a 10K resistor to the DNF pads on my board according to the minimal design example. Has anyone run into this issue and/or can help?

[embeddedbarsha]

I suggest you check your board with a multimeter. See if there is a broken trace or accidental short circuit.

[CoffeePlusPi]

Yes I have checked with a multimeter a few times…but I also tied down the 10K resistor and I haven’t really noticed any changes.

[trejan]

Show your schematic? If its always going into the UF2 bootloader then its not able to read flash.

[CoffeePlusPi]

Image 8-7-23 at 9.24 AM.jpeg (213.11 KiB) Viewed 4469 times

[hippy]

First thing I'd check is putting a scope on the Flash /CS to see what voltage it's seeing, when the link is shorted, and when it's booting. If it's not going low enough it won't read nor write the Flash, will always end up in BOOTSEL mode.

Then start probing elsewhere and hope you can spot something not quite right.

[arg001]

While the above is good advice, note that the problem might not be (probably isn't) a matter of it falsely detecting the bootmode selection.

Quite likely it is detecting the boot mode correctly and attempting to boot, but it fails to read the bootstrap from flash - either because it has a problem reading from flash, or because it never succeeded in writing to flash in the first place.

If you can look at it with a 'scope you should be able to see the difference - with the bootmode forced (button pressed, or link fitted on your board), there should be minimal activity on the flash as the ROM loaded samples the CS pin and goes direct to USB boot, while in the case of the button not pressed (link not fitted) but the flash blank/corrupt the ROM should try multiple times to load a valid boot image from the flash - so you should see a bunch of activity on nCS and SCLK before it times out and goes to USB boot by default.

[CoffeePlusPi]

Hi, thanks for the advice. I unfortunately do not have a scope nor used one. But while I was poking around Arduino and the IDE I saw that the only way to connect to my board in there is thru the hidden ports, under UF2 boards. That does not let me access the serial port, and that serial port seems non existent, since it doesn't pop up in the serial ports of Arduino, and I can't access the serial monitor / plotter. I am open to other solutions that could help here, thanks again!

[hippy]

I am open to other solutions that could help here, thanks again!

The problem appears to be that it keeps entering BOOTSEL mode on every reset. AFAIK the only reasons for that would be that it thinks the BOOTSEL button is held or it determines the Flash has not been programmed, which would be the case if the Flash wasn't present or wasn't enabled.

I believe, even in that state, you can upload and execute a 'Run from RAM' (no_flash) program which can create a virtual serial link back to the host, which would allow you to undertake some diagnostics. Not sure what diagnostics those would need to be though.

It would IMO be worth creating a simple 'Run from RAM' "Hello World!" program anyway, just to check that does work.

[CoffeePlusPi]

Thanks for the quick reply! How could i get a Run from RAM file, and/or how would flash not get programmed? I drag and drop the UF2 (for pico), and even with a suggested 10KΩ resistor, it will not accept the UF2 file. Would any of this affect why it does not show with a serial port in Arduino?

[hippy]

Thanks for the quick reply! How could i get a Run from RAM file

CMakeLists.txt

Code: Select all

set(PROJECT run_in_ram)
cmake_minimum_required(VERSION 3.12)
set(PICO_SDK_PATH $ENV{PICO_SDK_PATH})
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)

main.c

Code: Select all

#include <stdio.h>
#include "pico/stdlib.h"

int main() {
    stdio_init_all();
    while (!stdio_usb_connected()) {
        sleep_ms(100);
    }
    printf("Connected\n");
    while (true) {
         sleep_ms(1000);
         printf("Running from RAM\n");
    }
}

and/or how would flash not get programmed?

Hardware error or issue.

I drag and drop the UF2 (for pico), and even with a suggested 10KΩ resistor, it will not accept the UF2 file. Would any of this affect why it does not show with a serial port in Arduino?

Yes. If it doesn't get past BOOTSEL mode you won't ever see any serial port.

[hippy]

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 ?

[CoffeePlusPi]

The button was intended for any function, blink a light when addressed to the button press, etc. it has no function for putting the board into boot mode or anything like that.

[hippy]

It wasn't so much an aside comment on the functionality but the implementation, which seems rather risky to me.

[CoffeePlusPi]

Gotcha. I feel like I should note if I haven’t already, the RP2040 inserts as the USB drive and all that, but when I drop my UF2 file it downloads, ejects, and then remounts as the usb drive disregarding whether I hold the BOOTSEL pins together or not.

[hippy]

I feel like I should note if I haven’t already, the RP2040 inserts as the USB drive and all that, but when I drop my UF2 file it downloads, ejects, and then remounts as the usb drive disregarding whether I hold the BOOTSEL pins together or not.

I think we've all understood that. It points to a hardware issue as already said.

[CoffeePlusPi]

While the above is good advice, note that the problem might not be (probably isn't) a matter of it falsely detecting the bootmode selection.

Quite likely it is detecting the boot mode correctly and attempting to boot, but it fails to read the bootstrap from flash - either because it has a problem reading from flash, or because it never succeeded in writing to flash in the first place.

If you can look at it with a 'scope you should be able to see the difference - with the bootmode forced (button pressed, or link fitted on your board), there should be minimal activity on the flash as the ROM loaded samples the CS pin and goes direct to USB boot, while in the case of the button not pressed (link not fitted) but the flash blank/corrupt the ROM should try multiple times to load a valid boot image from the flash - so you should see a bunch of activity on nCS and SCLK before it times out and goes to USB boot by default.

So I made a scope using arduino, how would I use the scope to determine any issues on the board with the flash?

[CoffeePlusPi]

While the above is good advice, note that the problem might not be (probably isn't) a matter of it falsely detecting the bootmode selection.

Quite likely it is detecting the boot mode correctly and attempting to boot, but it fails to read the bootstrap from flash - either because it has a problem reading from flash, or because it never succeeded in writing to flash in the first place.

If you can look at it with a 'scope you should be able to see the difference - with the bootmode forced (button pressed, or link fitted on your board), there should be minimal activity on the flash as the ROM loaded samples the CS pin and goes direct to USB boot, while in the case of the button not pressed (link not fitted) but the flash blank/corrupt the ROM should try multiple times to load a valid boot image from the flash - so you should see a bunch of activity on nCS and SCLK before it times out and goes to USB boot by default.

Okay, I hooked the J2 pins (the ones you short to go into USB mode) up with a link so that they show an output in the scope I made with an Arduino UNO which works well. It is acting in the scope as mentioned above, with still no luck in flashing the image.

[hippy]

Okay, I hooked the J2 pins (the ones you short to go into USB mode) up with a link so that they show an output in the scope I made with an Arduino UNO which works well. It is acting in the scope as mentioned above, with still no luck in flashing the image.

So what does the scope show ?

[CoffeePlusPi]

Okay, I hooked the J2 pins (the ones you short to go into USB mode) up with a link so that they show an output in the scope I made with an Arduino UNO which works well. It is acting in the scope as mentioned above, with still no luck in flashing the image.

So what does the scope show ?

The scope flatlines at zero when not in USB mode, but when it is, some activity is shown and it spikes up to a 3.0 mark. Sorry if this isn’t all that clear, I’m not entirely sure how to say readings of a scope, this is just what I saw.

[hippy]

There are two control signals to the Flash, QSPI_SS (CS\) and QSPI_SCLK, plus four data signals QSPI_D0 to QSPI_D3.

Ideally one would monitor all signals so one can observe the relationship and timing between them, but the first two are perhaps the most important to start with. Which signal are you monitoring ?

Generally nothing beats a photo, and better still a screen-shot, of what a scope is showing rather than a description of that.

Before getting into analysing the Flash interface it would be prudent to check the crystal oscillator and its frequency. I am not sure an Arduino-based scope will be good enough for that but it's perhaps worth trying it anyway. - Maybe not necessary as it's appearing as an MSD BOOTSEL drive which means things are good enough to enumerate as a USB device.

It has to be said; you do not have fault-finding experience, don't have the experience to diagnose the issue yourself, don't have the tools to easily do that, nor experience of using those. There's no shame in that; many, perhaps most, would struggle in the same situation you find yourself in; 'built it, doesn't work'.

Unfortunately remote diagnostics isn't easy. It can be a long, tortuous and frustrating process which most people will prefer to steer well clear of. It usually involves a lot of investment to fix something which may have been trivial to identify and resolve with hands-on access, and the effort required can easily exceed the effort people are prepared to put in.

I still think you would be better off, most likely to resolve your issue, if you can find someone who can help you with hands-on access.

We are over 50 days in to trying to resolve this issue and I am not convinced we are close to doing so yet. I would anticipate, with experience and the right tools, it could be solved in a day, perhaps within hours, with hands-on access.

[hippy]

Did you ever try the Run form RAM code suggested here - viewtopic.php?p=2131140#p2131140 ?

[arg001]

Okay, I hooked the J2 pins (the ones you short to go into USB mode) up with a link so that they show an output in the scope I made with an Arduino UNO which works well. It is acting in the scope as mentioned above, with still no luck in flashing the image.

So what does the scope show ?

The scope flatlines at zero when not in USB mode, but when it is, some activity is shown and it spikes up to a 3.0 mark. Sorry if this isn’t all that clear, I’m not entirely sure how to say readings of a scope, this is just what I saw.

It's not quite clear what you mean by 'in USB mode', but flatlining at zero seems surprising in any mode (except if you fit the jumper on J2 at the same time as the scope in which case it will obviously read zero).

What you are expecting is that pin 1 on the chip (which you are measuring via the 1K resistor) will go high soon after power-on, regardless of operating mode. If it is in bootrom mode and you then drag a .UF2 file onto it, then you should see some activity on that pin while the file is written to flash. That's worth checking, but is almost certainly happening.

More interesting is the behaviour immediately after power-up: you expect the pin to go high, then a short time later a series of pulses as it loads codes from the flash, then mostly high (or always high) if the code successfully loads and runs.

One thing which would be useful is to attach a push-button between RUN and GND. It's sometimes difficult to make measurements immediately after power-on as everything is unstable and you don't know when 'start time' is, so if you have a reset button you can start the process at a time of your choosing. It's also possible that this will make your board work: one failure mode is if the power supply starts too slowly.

You may have difficulty making measurements of high-speed signals with your setup. Software-based scopes are often rather slow, and also you are currently measuring through a 1K resistor: the combination of that 1K and the input capacitance of the scope will mean that fast moving signals will be slowed down, and very fast pulses may disappear altogether.

[CoffeePlusPi]

Did you ever try the Run form RAM code suggested here - viewtopic.php?p=2131140#p2131140 ?

I still have yet to try this, I never did it because i figured if the board won’t load the pico UF2 it won’t load this, but I’ll give it a go.

[hippy]

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.