RP2040 Initial Boot (USB Issues) - Page 1
Forum section: electronics / general

author: machinehum
author_rank: Contributor
timestamp: June 21, 2023, 02:32:04 am
content: I spun a board with the RP2040 in a pretty "normal" configuration, similar to the pico. Here:https://pastebin.com/dLRzbpWris the error I'm getting. Is there a special button sequence or JTAG flash that is required?

author: ataradov
author_rank: Super Contributor
timestamp: June 21, 2023, 02:47:43 am
content: 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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: June 21, 2023, 03:31:47 am
content: 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

author: ataradov
author_rank: Super Contributor
timestamp: June 21, 2023, 03:45:51 am
content: 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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: June 21, 2023, 04:43:44 am
content: Quote from: ataradov on June 21, 2023, 03:45:51 amI 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.Quote from: ataradov on June 21, 2023, 03:45:51 amThat'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.Quote from: ataradov on June 21, 2023, 03:45:51 amI 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.

author: ataradov
author_rank: Super Contributor
timestamp: June 21, 2023, 04:54:56 am
content: Quote from: SiliconWizard on June 21, 2023, 04:43:44 amYes, but it is alive enough to enable the pull-up resistor to indicate its presence to the host.Quote from: SiliconWizard on June 21, 2023, 04:43:44 amSection "Processor Controlled Boot Sequence" describes in a lot of details the boot processThe relevant part:Quote

author: SiliconWizard
author_rank: Super Contributor
timestamp: June 21, 2023, 05:10:49 am
content: 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.

author: ataradov
author_rank: Super Contributor
timestamp: June 21, 2023, 02:58:42 pm
content: 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.

author: machinehum
author_rank: Contributor
timestamp: June 21, 2023, 05:40:20 pm
content: Here's the schematic.

author: machinehum
author_rank: Contributor
timestamp: June 21, 2023, 05:59:07 pm
content: The USB termination resistors were popped as the wrong value, fixed that and things are coming up now! Thanks for your help!

author: ataradov
author_rank: Super Contributor
timestamp: June 21, 2023, 06:01:39 pm
content: 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.

author: ataradov
author_rank: Super Contributor
timestamp: June 21, 2023, 06:02:21 pm
content: Quote from: machinehum on June 21, 2023, 05:59:07 pmYou should still add CCx pull-down resistors.

author: SiliconWizard
author_rank: Super Contributor
timestamp: June 21, 2023, 08:12:40 pm
content: Quote from: ataradov on June 21, 2023, 06:02:21 pmYes, 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.

author: machinehum
author_rank: Contributor
timestamp: June 21, 2023, 08:16:11 pm
content: Quote from: ataradov on June 21, 2023, 06:02:21 pm10-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.

author: ataradov
author_rank: Super Contributor
timestamp: June 21, 2023, 08:36:37 pm
content: 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?

author: machinehum
author_rank: Contributor
timestamp: June 21, 2023, 11:01:34 pm
content: Quote from: ataradov on June 21, 2023, 08:36:37 pmUSB4105-GF-A