RP2040 won't go to built-in USB loader

[phil from seattle]

I've designed an RP2040 based board and it won't allow use of the built-in USB boot loader.  I used the "Hardware Design with the RP2040" document from RasPi folks and followed their recommendations. I've got 3V for VCC and the chip is outputting 1.1V. The crystal is oscillating at 12 mhz. With a logic analyzer, I can see the QSPI memory signals from the 2040 to the W25Q128JVS so I'm pretty sure it is running.  When I go to pull the /CS pin of the W25Q128JVS to ground via a 1K resistor and SW1 (see schematic) as specified in the HDwtRP2040 document, it does not pull the /CS pin anywhere close to 0V but rather about 100 mV below VCC.  (in my case it is 3V and /CS gets pulled down to 2.9V)  I verified that R1 is indeed 1K and SW functions correctly.  I think this means the RP2040 is asserting /CS high. But I don't understand what is causing that. I can see /CS toggle in the logic analyzer so it's probably not shorted to VCC.  Any help would be greatly appreciated.

FWIW, I don't like the 3.3V and 1.1V distribution layout and have reworked for the next turn of the board.  I doubt that is the cause of my problem, though.

[ataradov]

The value of the SS is sampled on reset or power cycle. Pulling it low when MCU is already running will not do anything. So, press the SS button while it is not plugged into USB, then plug it in and release the button. It should stay in the bootloader.

[phil from seattle]

I do that - pull Run down, Pull /CS down, release Run (pulls up) and then release /CS.  Nothing happens. Maybe it's a USB problem?  I think my layout looks ok, maybe not.

[edit]  Instead of pulling Run low, I tried hold the /CS low while plugging in USB.  Same thing - no response.  Windows Dev Manager doesn't show anything.  I am getting VUSB, though.

[ataradov]

The layout is fine, it is hard to screw up USB FS layout.

Measure level on the SS after you release reset, but before you release the button. Does it stay low?

What are the voltage levels on the DP/DM lines? Does it pull DP high? Does the crystal oscillate? Is the frequency correct?

But also, if this is a brand new flash, then it would boot into the ROM anyway, so it should enumerate regardless of what you hold down.

[phil from seattle]

Here are 2 LA traces -  first is with /CS held low, toggle Run, release /CS.  No activity.  Second is with just toggling Run.  Activity but nothing in Flash so nothing runs. 

Crystal show 12MHz in scope.

DM is 5V, DP is 1.25V - reversed?

[ataradov]

DM/DP are 3.3 V level signals. There is something really wrong on your board. Look for shorts.

[phil from seattle]

thanks for all your help.  I do appreciate it.

I had 5 boards made and 4 of them exhibit the same behavior.  (the 5th had the crystal mounted upside down so it exhibits dead behavior). 

will double check the voltage measurements - it's tricky getting in to read them.

[phil from seattle]

Reading on the RP2040 side of the resistors I see DM with 2.95 (VCC is 3V) and DP with 0 (6mV).

[ataradov]

And do they both go to 0V when you hold it in reset?

DM being high means that it wants to enumerate as a low speed device. This is strange.

But at the same time, any of them being high is enough for the OS to start the enumeration process, so this device should at least appear in the device manager, probably with an exclamation mark.  This would be accompanied by some error message.

[SiliconWizard]

I see two things not quite right with your schematic. I can't guarantee that causes a problem, but definitely not how I've used the RP2040 nor what i've seen on other schematics with it.

First, the RUN pin is left floating (unless you short it to GND). I've always put a pull-up resistor (10k) to VDD. I haven't double-checked in the DS whether it was safe to leave it floating.
The second, probably more problematic here: you need a pull-up resistor (also typ. 10k) between the /CS pin of the Flash and VDD. I don't think there's any internal pull-up, so when the MCU is sampling it at boot, I think it is essentially floating until it gets controlled by the MCU. I don't know the exact way it's implemented inside, but I would think that when you release the SW1 switch, the MCU will wait for a high-level before getting control of it (otherwise it would just cause a short-circuit), and if there's no external pull-up, it probably gets confused enough for the bootloader not to do what's expected.

On the schematic level, that's about the 2 things I've noted. So something to try first.

If it's still not working, you may also check the soldering. QFNs can be pesky. Especially if it was hand-soldered. But check the above first.

[phil from seattle]

Thanks.  The /CS pullup is listed as optional and not needed for the W25Q128.  I did check and it shows being pulled to VCC so it isn't floating.  I will put a resistor on it to see though. Run pin is left floating in every implementation I've seen, including the Pico. At this point though, I'll give it a try.

[EDIT]  Tried both pullups. No joy.

I see two things not quite right with your schematic. I can't guarantee that causes a problem, but definitely not how I've used the RP2040 nor what i've seen on other schematics with it.

First, the RUN pin is left floating (unless you short it to GND). I've always put a pull-up resistor (10k) to VDD. I haven't double-checked in the DS whether it was safe to leave it floating.
The second, probably more problematic here: you need a pull-up resistor (also typ. 10k) between the /CS pin of the Flash and VDD. I don't think there's any internal pull-up, so when the MCU is sampling it at boot, I think it is essentially floating until it gets controlled by the MCU. I don't know the exact way it's implemented inside, but I would think that when you release the SW1 switch, the MCU will wait for a high-level before getting control of it (otherwise it would just cause a short-circuit), and if there's no external pull-up, it probably gets confused enough for the bootloader not to do what's expected.

On the schematic level, that's about the 2 things I've noted. So something to try first.

If it's still not working, you may also check the soldering. QFNs can be pesky. Especially if it was hand-soldered. But check the above first.

[phil from seattle]

And do they both go to 0V when you hold it in reset?

DM being high means that it wants to enumerate as a low speed device. This is strange.

But at the same time, any of them being high is enough for the OS to start the enumeration process, so this device should at least appear in the device manager, probably with an exclamation mark.  This would be accompanied by some error message.

Nothing shows in Dev Manager.  Both DM and DP are 0V when Run is pulled to Gnd.

What would cause an enumeration for low speed?

[ataradov]

What would cause an enumeration for low speed?

No idea. Something is just wrong, I don't even know if ROM would ever try LS, I see no reason for it to do that.

The host has 15 kOhm pull-downs on both lines. When device wants to attach it enables 1.5 kOhm pull-up on DP for FS/HS and on DM for LS.

The resistive divider would mean that the voltage on the pin would be 0.9 * 3.3 V = 2.97 V, which is exactly what you see. It is strange that OS does not show any errors.

I have no idea what is going on. I would probably try to put a scope or a logic analyzer on DP/DM and check if there are any packets sent at all.

[SiliconWizard]

Thanks.  The /CS pullup is listed as optional and not needed for the W25Q128.  I did check and it shows being pulled to VCC so it isn't floating.  I will put a resistor on it to see though. Run pin is left floating in every implementation I've seen, including the Pico. At this point though, I'll give it a try.

Actually, a pull-up would be needed for the W25Q128, which can be read in its datasheet, so there's nothing special with this flash chip that would not require it. (If the MCU didn't have an internal pull-up, it would definitely be required.)

But looking back at the RP2040 datasheet, it looks like the reset state of both the RUN and QSPI_SS pins is with a pull-up enabled, so I guess that should work without external pull-ups, which explains why the Pico doesn't have them. The Pico's schematic shows a "DNI" pull-up for the /CS signal, and in the Pico board I physically have, there's a footprint but it's indeed not populated.
So, these external pull-ups shouldn't be strictly necessary, unless there's an errata regarding this with the RP2040, I haven't checked. I have put both pull-ups in my own designs. If nothing else, I'm rarely comfortable with just internal weak pull-ups, which are often > 50k. More sensitive to EMI than a well defined, 10k pull-up.

I suppose your boards have not been hand-assembled then, and that soldering is not likely to be an issue?

[phil from seattle]

What would cause an enumeration for low speed?

No idea. Something is just wrong, I don't even know if ROM would ever try LS, I see no reason for it to do that.

The host has 15 kOhm pull-downs on both lines. When device wants to attach it enables 1.5 kOhm pull-up on DP for FS/HS and on DM for LS.

The resistive divider would mean that the voltage on the pin would be 0.9 * 3.3 V = 2.97 V, which is exactly what you see. It is strange that OS does not show any errors.

I have no idea what is going on. I would probably try to put a scope or a logic analyzer on DP/DM and check if there are any packets sent at all.

OK, will do that.  Going to take a little time.  Kind of wishing I had designed with 603s instead of 402. Still possible, just trickier.

[phil from seattle]

Thanks.  The /CS pullup is listed as optional and not needed for the W25Q128.  I did check and it shows being pulled to VCC so it isn't floating.  I will put a resistor on it to see though. Run pin is left floating in every implementation I've seen, including the Pico. At this point though, I'll give it a try.

Actually, a pull-up would be needed for the W25Q128, which can be read in its datasheet, so there's nothing special with this flash chip that would not require it. (If the MCU didn't have an internal pull-up, it would definitely be required.)

But looking back at the RP2040 datasheet, it looks like the reset state of both the RUN and QSPI_SS pins is with a pull-up enabled, so I guess that should work without external pull-ups, which explains why the Pico doesn't have them. The Pico's schematic shows a "DNI" pull-up for the /CS signal, and in the Pico board I physically have, there's a footprint but it's indeed not populated.
So, these external pull-ups shouldn't be strictly necessary, unless there's an errata regarding this with the RP2040, I haven't checked. I have put both pull-ups in my own designs. If nothing else, I'm rarely comfortable with just internal weak pull-ups, which are often > 50k. More sensitive to EMI than a well defined, 10k pull-up.

I suppose your boards have not been hand-assembled then, and that soldering is not likely to be an issue?

I edited my last response - pullups tried but no luck.

The board was built by JLCPCB and microscope inspection of the soldering looks good.  sigh.

one thing I'm going to do is get a pico probe going to see if I can load a uf2.  Unfortunately, that has problems too...  I can't get windows to recognize the pico as a probe so yet another rabbithole.

[SiliconWizard]

Don't you have some SWD adapter so you can program the MCU via SWD? If not, that's something really useful to have.

The exposed pad of the RP2040 is connected to GND with the 4 vias, to - I suppose - a GND plane on the bottom layer?

[phil from seattle]

Don't you have some SWD adapter so you can program the MCU via SWD? If not, that's something really useful to have.

The exposed pad of the RP2040 is connected to GND with the 4 vias, to - I suppose - a GND plane on the bottom layer?

Here's the bottom.  Mostly ground.  The red box is the location of the RP2040.

Yes, I have lots of Picos that can be set up as SWD programmers. Unfortunately, I'm having trouble getting OpenOCD to recognize a Pico. Sigh. But that's for a different day.   My product must have USB programmability so I definitely need to figure this out. 

[phil from seattle]

here's what I'm seeing. /CS and RUN are input by me. I'm not 100% sure of the DM connection - soldering to 402 resistors is kind of tricky. need to find a better way to probe them.

Anyway, it looks like nothing is happening on the USB lines other than the 2040 raising DP upon RUN rising to VCC.

[ataradov]

Ok, but now DP is high. Previously it was DM. What changed? What are the measured voltage levels on each line?

This DP high is enough for the host to start enumeration, this is all the information it gets when any device is connected. Check that this USB port is not broken somehow.

[SiliconWizard]

I'm starting to doubt the pinout of your footprint for the micro-USB connector. Namely, it may look like D+ and D- are exchanged.

[phil from seattle]

Ok, but now DP is high. Previously it was DM. What changed? What are the measured voltage levels on each line?

This DP high is enough for the host to start enumeration, this is all the information it gets when any device is connected. Check that this USB port is not broken somehow.

Probably because I got them backwards when looking at the board upside down. Sorry 'bout that.

I can connect to other USB devices with the same port and cable.  Just tried a different port and cable and got same results.  I can run a RasPi Pico off the same cable - USB
plug in with /CS toggle gets enumeration to happen.

[phil from seattle]

I'm starting to doubt the pinout of your footprint for the micro-USB connector. Namely, it may look like D+ and D- are exchanged.

Yeah, I thought that too but it is the same as numerous other RP2040 examples - no cross-over of the USB lines needed.

[SiliconWizard]

Not sure exactly what crossover you're talking about, but the pin right next to VBUS on the connector should definitely be D-, but looking at your layout, this pin seems connected to R2 (unless you've swapped the silkscreen), which is connected to D+ of the RP2040.

[phil from seattle]

Not sure exactly what crossover you're talking about, but the pin right next to VBUS on the connector should definitely be D-, but looking at your layout, this pin seems connected to R2 (unless you've swapped the silkscreen), which is connected to D+ of the RP2040.

RP2040 pin 46 is DM and pin 47 is DP.  pin 2 of the USB connector connects to R2 which connects to pin 46.  pin 3 of the USB connector connects to R3 which connects to pin 47.  Is that backwards?

By no crossover, I meant that you don't need to switch the USB lines from the connector to the microprocessor (ie they go straight to the uP).

[ataradov]

Connectors look correct to me.

But the lack of enumeration from the host is on the host, not the device. May be capture a bit longer trace to see if host takes a couple seconds to start doing something.

The absolute minimal "USB device" is 1.5 kOhm resistor between 3.3 V and D+. This is enough for the host to reset the bus (both D+/D- low for ~100 ms) and send the device descriptor request. At this point host has no way of knowing if the device is real or just a resistor.

[SiliconWizard]

Not sure exactly what crossover you're talking about, but the pin right next to VBUS on the connector should definitely be D-, but looking at your layout, this pin seems connected to R2 (unless you've swapped the silkscreen), which is connected to D+ of the RP2040.

RP2040 pin 46 is DM and pin 47 is DP.  pin 2 of the USB connector connects to R2 which connects to pin 46.  pin 3 of the USB connector connects to R3 which connects to pin 47.  Is that backwards?

According to your schematic, R2 connects to pin 47, which is USB_P (D+). What did I miss?

By no crossover, I meant that you don't need to switch the USB lines from the connector to the microprocessor (ie they go straight to the uP).

Yes, of course. D+ of the connector to D+ of the MCU, and ditto for D-.

[phil from seattle]

Not super easy to read but here's what I sent to the fab.  The resistor numbers might be confusing. R2 is for the left resistor, R3 for the right. RP2040 on top, USB connector on the bottom.

[phil from seattle]

Thanks for all your help, I really do appreciate it. Tried without  a hub and on a different computer. no change.  I also buzzed out the USB connector and have continuity for all the pins on the connector.  Not sure what my next steps will be.

[ataradov]

Are you sure about that? It looks like labels are swapped either here or on the schematic. R3 is Pin46 and DM according to the schematic. This is the left resistor.

But the actual routing is correct. So, it must be some mixup with the labels.

Your next step is to figure out why PicoProbe does not work. There seems to be something really wrong with your computer.

You can even do the experiment with the resistor and you should see USB traffic, at least the SOFs and a request for the device descriptor.

[phil from seattle]

The labels are that way because there no room.

[ataradov]

Ok, but then your description "R2 is for the left resistor, R3 for the right" is not correct.  Resistor R3 is on the left.

[phil from seattle]

oof, you are right.  Not sure how I missed that.