RP2040 Initial Boot (USB Issues)

[machinehum]

I spun a board with the RP2040 in a pretty "normal" configuration, similar to the pico. Here: https://pastebin.com/dLRzbpWr is the error I'm getting. Is there a special button sequence or JTAG flash that is required?

[ataradov]

There is something wrong with your design. There is no button that would help here. So, share your normal schematic and layout.

The external checks you can do is see if the crystal oscillator oscillates at the right frequency and if the power supplies (main and core) are within expected ranges.

[SiliconWizard]

Show us a schematic?
Is the flash memory blank, your board is powered by USB and you're just plugging the board into a USB host without doing anything else?

The RP2040 bootloader will boot in USB "DFU" mode if the QSPI_SS pin is held low when the CPU is reset (/ upon power-on). The device will appear as USB mass storage.
If you have no means of pulling this pin down to force this mode, it will just execute whatever is in the flash memory instead.

What I don't know is if it automatically boots in USB DFU mode if you don't pull the QSPI_SS low while resetting but the flash is completely blank. I have never tried it. I suspect not though. Which would explain what you are seeing. But maybe someone can confirm (or not) that it automatically boots in USB DFU mode if the flash is blank.
The Pico board has a BOOTSEL pin that serves this purpose - you can have a look at its schematic and otherwise read this if you haven't already: https://datasheets.raspberrypi.com/rp2040/hardware-design-with-rp2040.pdf

[ataradov]

The linked logs show that it does not accept the address, so fails to enumerate.

It uses CRC of the first 256 bytes to determine if the flash contents is valid, so an empty flash, or even flash programmed with random data would result in it booting in a DFU mode.

And it tries to start USB, but fails.

[SiliconWizard]

The linked logs show that it does not accept the address, so fails to enumerate.

I haven't looked at the complete log, but what appears is just that the device fails to reply to pretty much any request from the host. So, acting like dead beef.

It uses CRC of the first 256 bytes to determine if the flash contents is valid, so an empty flash, or even flash programmed with random data would result in it booting in a DFU mode.

That's what I was not sure about. I don't think I have found anything about this in the datasheet though. Can you point me to the doc that states it? (I believe you, I just tried with a Pico board i had in a drawer that was never used, so I'm assuming the flash was blank, and it does boot in DFU mode automatically.) Would like to see it clearly stated though. If you have a ref.

That said, this is a handy feature then, but I would still recommend providing a way of forcing it like the Pico does with BOOTSEL - because otherwise, programming the device with the USB bootloader is going to be a one-time thing, unless you program your own bootloader on the first try. Or otherwise you'll have to use SWD.

And it tries to start USB, but fails.

I think all it would take for the USB stack to try as it is and fail in this way would be to just connect a pull-up between the D+ line and a 3.3V supply. So it doesn't tell much except that something that looks like a pull up is connected between those. I'll try this one of these days, but I'm pretty sure that's all it would take to trigger an enumeration attempt (with of course no reply to any of the USB requests.) I may have missed one valid reply in the posted log though, but I don't think I've seen any.

For the OP, one thing to check would be if he put a *12MHz* crystal on his board, as it's the only way the USB bootloader will work properly, as the datasheet states.
(Whereas if you're implementing USB in your own firmware, I think you could generate a valid clock for the USB peripheral from a different crystal. But for the bootloader, it's fixed.)
And of course, check that D+ and D- are not swapped.

[ataradov]

I haven't looked at the complete log, but what appears is just that the device fails to reply to pretty much any request from the host. So, acting like dead beef.

Yes, but it is alive enough to enable the pull-up resistor to indicate its presence to the host.

Would like to see it clearly stated though. If you have a ref.

Section "Processor Controlled Boot Sequence" describes in a lot of details the boot process

The relevant part:

- Check if SPI CS pin is tied low ("bootrom button"), and skip flash boot if so.
- Set up IO muxing, pad controls on QSPI pins, and initialise Synopsys SSI for standard SPI mode
- Issue XIP exit sequence, in case flash is still in an XIP mode and has not been power-cycled
- Copy 256 bytes from SPI to internal SRAM (SRAM5) and check for valid CRC32 checksum
- If checksum passes, assume what we have loaded is a valid flash second stage
- Start executing the loaded code from SRAM (SRAM5)
- If no valid image found in SPI after 0.5 seconds of attempting to boot, drop to USB device boot
- USB device boot: appear as a USB Mass Storage Device

[SiliconWizard]

Ah thanks, it's in the "Bootrom" section. This is a relatively elaborate bootloader.

To the OP, now again the most likely culprit is either not a proper 12MHz crystal, or swapped/improperly connected D+/D-.
If he forgot to add a crystal (+ capacitors) altogether (or provide a 12MHz clock directly to XIN), then there's unfortunately no way USB is going to work in the bootloader.

[ataradov]

Looking at the log, it says that full-speed device is attached, so the D+/D- polarity must be correct.

Oscillator is the likely reason, incorrect power supplies is the other.

[machinehum]

Here's the schematic.

[machinehum]

The USB termination resistors were popped as the wrong value, fixed that and things are coming up now! Thanks for your help!

[ataradov]

Having USB mux is not "normal" and something worth mentioning upfront  when dealing with USB issues.

You Type-C plug is missing pull-down resistors on CCx lines. This may prevent enumeration on some hosts (especially with Type-C connector on the host side), but in this specific case it is not the issue, since host did notice the device.

I would bypass the mux and try without it.

[ataradov]

The USB termination resistors were popped as the wrong value, fixed that and things are coming up now! Thanks for your help!

You should still add CCx pull-down resistors.

[SiliconWizard]

The USB termination resistors were popped as the wrong value, fixed that and things are coming up now! Thanks for your help!

You should still add CCx pull-down resistors.

Yes, otherwise the device is not gonna work if you plug it to a USB-C host, which you won't notice otherwise using a USB-C to USB-A cable (which may make you state that CCx resistors are useless. They aren't.)

What's the deal with R45 on the schematic? If you short it (is it what the cross means?), then the BOOTSEL pushbutton is just gonna short the power supply when you press it. It's gonna hurt.
If the cross means 'do not populate', then the /CS will never get pulled up. Gonna hurt too.
The pull-up/BOOTSEL arrangement is not quite correct here. R45 should be typically 10k and the 1k resistor should be in series with the pushbutton, not in series with the /CS pin.

As to the series resistors on the USB lines, they are "recommended" but certainly it will also work without any, especially if you're using the USB MUX.

[machinehum]

The USB termination resistors were popped as the wrong value, fixed that and things are coming up now! Thanks for your help!

You should still add CCx pull-down resistors.

10-4.

The only reason I didn't mention the mux was because it worked fine to connect to the serial chip. I won't forget to mention this next time.

[ataradov]

What type of USB connector are you using? Is it a typical 12-pin one, or did you actually find one with just the set of pins shown on the schematic?

[machinehum]

What type of USB connector are you using? Is it a typical 12-pin one, or did you actually find one with just the set of pins shown on the schematic?

USB4105-GF-A