RP2040 is always a Full-speed USB device when in device mode (whether for BOOTSEL or otherwise). In host mode, it can operate at Low-speed to talk to low-speed devices like keyboards. Note that RP2040 doesn't do USB High-speed at all.
But you are on the wrong track here talking about USB. USB isn't your problem with this board. If you fixed the other problems, I'd bet serious money that the USB will work just fine as you have it now. What goes wrong when you get out of bootrom mode is that your application (or the Pico SDK) switches the CPU and flash to full speed.
The CPU runs at 125MHz or more.
The flash (after booting) normally runs at half the CPU speed, so 62.5MHz.
The USB runs at 12MHz (actually, 12Mbit/sec so only 6MHz toggle speed).
So that's the order of priority whether you are talking about a new layout or patching up your existing one to try and get some life out of it.
Ground is really important for all of the above. The thing people always seem to forget when talking about decoupling is that current flows around a circuit, so when we say that the decoupling capacitors should be "close" to the device pins they decouple, that distance is the total length of both the +V track from capacitor to RP2040 power pin PLUS the length of track from the negative end of the capacitor back to the GND pad on the bottom of the RP2040. Furthermore, for most I/O signals they don't care much how long the tracks are so long as they are paired consistently with a ground track/plane. So for a good RP2040 layout you should consider using a 4-layer PCB (which makes it easy and really isn't that expensive nowadays), or if you want to do a 2-layer design then you have to give priority to ground - effectively do a single-layer design and just use the blue side for ground and a few short links where tracks have to cross over each other. If this means that slow I/O signals have to take a long trip around the outside edges of the board then that's the right thing to do (though it takes up a lot of space so you want to pick your GPIO allocations to make things easy if you can). If the USB has to take a few extra centimetres to exit the board it really doesn't matter (you are going to be adding a metre or more of cable after all).
So, if you are trying to fix up these PCBs the obviously the first thing is to fix up the missing links that somehow escaped DRC. The 3V3 can just be a simple wire connecting any two convenient points, as you've got decoupling capacitors on both sides of the break (remember that the CPU is in effect powered by the decoupling capacitors - the PSU is too slow to do that job and just serves to keep the decouplers 'topped up'). The Ground is another matter - it affects both the power delivery and the integrity of the signals going to the flash device. You've got effectively three islands of ground - under the flash chip, under the CPU, and under the PSU area (albeit two of them are connected in a circuitous manner - that's not good enough at 125MHz). So you want to scrape off some resist and connect some copper tape/braid or lots of wires to link those three areas together.
Finally there's the problem that the decoupling capacitors are too far away. I'm particularly concerned about the ones on the 1.1V supply - this runs all the internal digital logic, and there's the on-chip regulator that generates it which may be unstable with the capacitors so far away. I can't see an easy fix for this - normally that side of the chip has the capacitors really tightly packed as there are so many power pins (and the USB pins and the flash pins all in a small area). But you've got none at all and the tracking only under the chip so not exposed anywhere. Also, there are supposed to be three capacitors on that rail - two small ones for decoupling the CPU, one larger one for stability of the regulator. You could consider stacking some more on top of the two capacitors you already have.
Having patched up the hardware as best you can, you can tweak the software to run the machine less hard. The flash speed is easily changed with the constant PICO_FLASH_SPI_CLKDIV that you can specify in your CMakefile or on the command line - the default is 2, but setting it to 4 or 8 will run the flash more slowly. You can also call set_sys_clock_khz() to select a slower CPU clock, though it's tricky to do this early enough to avoid the SDK selecting 125MHz before you turn it back down again.
But you are on the wrong track here talking about USB. USB isn't your problem with this board. If you fixed the other problems, I'd bet serious money that the USB will work just fine as you have it now. What goes wrong when you get out of bootrom mode is that your application (or the Pico SDK) switches the CPU and flash to full speed.
The CPU runs at 125MHz or more.
The flash (after booting) normally runs at half the CPU speed, so 62.5MHz.
The USB runs at 12MHz (actually, 12Mbit/sec so only 6MHz toggle speed).
So that's the order of priority whether you are talking about a new layout or patching up your existing one to try and get some life out of it.
Ground is really important for all of the above. The thing people always seem to forget when talking about decoupling is that current flows around a circuit, so when we say that the decoupling capacitors should be "close" to the device pins they decouple, that distance is the total length of both the +V track from capacitor to RP2040 power pin PLUS the length of track from the negative end of the capacitor back to the GND pad on the bottom of the RP2040. Furthermore, for most I/O signals they don't care much how long the tracks are so long as they are paired consistently with a ground track/plane. So for a good RP2040 layout you should consider using a 4-layer PCB (which makes it easy and really isn't that expensive nowadays), or if you want to do a 2-layer design then you have to give priority to ground - effectively do a single-layer design and just use the blue side for ground and a few short links where tracks have to cross over each other. If this means that slow I/O signals have to take a long trip around the outside edges of the board then that's the right thing to do (though it takes up a lot of space so you want to pick your GPIO allocations to make things easy if you can). If the USB has to take a few extra centimetres to exit the board it really doesn't matter (you are going to be adding a metre or more of cable after all).
So, if you are trying to fix up these PCBs the obviously the first thing is to fix up the missing links that somehow escaped DRC. The 3V3 can just be a simple wire connecting any two convenient points, as you've got decoupling capacitors on both sides of the break (remember that the CPU is in effect powered by the decoupling capacitors - the PSU is too slow to do that job and just serves to keep the decouplers 'topped up'). The Ground is another matter - it affects both the power delivery and the integrity of the signals going to the flash device. You've got effectively three islands of ground - under the flash chip, under the CPU, and under the PSU area (albeit two of them are connected in a circuitous manner - that's not good enough at 125MHz). So you want to scrape off some resist and connect some copper tape/braid or lots of wires to link those three areas together.
Finally there's the problem that the decoupling capacitors are too far away. I'm particularly concerned about the ones on the 1.1V supply - this runs all the internal digital logic, and there's the on-chip regulator that generates it which may be unstable with the capacitors so far away. I can't see an easy fix for this - normally that side of the chip has the capacitors really tightly packed as there are so many power pins (and the USB pins and the flash pins all in a small area). But you've got none at all and the tracking only under the chip so not exposed anywhere. Also, there are supposed to be three capacitors on that rail - two small ones for decoupling the CPU, one larger one for stability of the regulator. You could consider stacking some more on top of the two capacitors you already have.
Having patched up the hardware as best you can, you can tweak the software to run the machine less hard. The flash speed is easily changed with the constant PICO_FLASH_SPI_CLKDIV that you can specify in your CMakefile or on the command line - the default is 2, but setting it to 4 or 8 will run the flash more slowly. You can also call set_sys_clock_khz() to select a slower CPU clock, though it's tricky to do this early enough to avoid the SDK selecting 125MHz before you turn it back down again.
Statistics: Posted by arg001 — Wed Jul 03, 2024 10:56 am