I think @dp11 comment was rather diplomatic: this layout is extremely poor!
Ironically, the fact that the crystal is half a mile away from the RP2040 (usually a criticism) maybe adds enough stray capacitance to make up for the missing loading capacitors - if it's coming up as a USB MSC device then the crystal must be running.
As others have said, your immediate problem is that the QSPI_SS is shorted to 3V3, but that's probably easy enough fixed with a scalpel.
However, you will almost certainly then find that you can load code into it but it will then crash on startup: there's been lots of similar non-working designs posted here with the same mistakes. With the poor power layout, the RP2040 will start up OK in the bootrom which does not run the CPU/flash at full speed, but will crash as soon as the application starts up and tries to go to full-speed.
When I say it's extremely poor, I'm talking mainly about the power distribution. You can't just put all the decoupling capacitors in a long row: the reason that there's 7 of them on the design is that there is supposed to be one capacitor very close to each power pin on the RP2040, and also the other end of those capacitors must have a short, low impedance path back to the ground pin on the bottom of the RP2040. Same goes for the capacitors on the 1V1 rail.
These connections to the decoupling capacitors are the highest speed, most critical connections on almost any RP2040 design, and should be the first things placed on your layout. Next most sensitive are the flash and the crystal. Anything you might connect to a GPIO is likely to be much slower and so lower priority - if necessary they can take 'the long way round' to keep the area under the RP2040 clear for groundplane.
Ironically, the fact that the crystal is half a mile away from the RP2040 (usually a criticism) maybe adds enough stray capacitance to make up for the missing loading capacitors - if it's coming up as a USB MSC device then the crystal must be running.
As others have said, your immediate problem is that the QSPI_SS is shorted to 3V3, but that's probably easy enough fixed with a scalpel.
However, you will almost certainly then find that you can load code into it but it will then crash on startup: there's been lots of similar non-working designs posted here with the same mistakes. With the poor power layout, the RP2040 will start up OK in the bootrom which does not run the CPU/flash at full speed, but will crash as soon as the application starts up and tries to go to full-speed.
When I say it's extremely poor, I'm talking mainly about the power distribution. You can't just put all the decoupling capacitors in a long row: the reason that there's 7 of them on the design is that there is supposed to be one capacitor very close to each power pin on the RP2040, and also the other end of those capacitors must have a short, low impedance path back to the ground pin on the bottom of the RP2040. Same goes for the capacitors on the 1V1 rail.
These connections to the decoupling capacitors are the highest speed, most critical connections on almost any RP2040 design, and should be the first things placed on your layout. Next most sensitive are the flash and the crystal. Anything you might connect to a GPIO is likely to be much slower and so lower priority - if necessary they can take 'the long way round' to keep the area under the RP2040 clear for groundplane.
Statistics: Posted by arg001 — Sat Jan 18, 2025 8:41 pm