The flash chips used support both a basic SPI mode, and an advanced QSPI mode. There is a well-defined standard protocol for basic SPI mode, so virtually all chips will respond to the same read command for simple slow byte-by-byte reading. The only thing left to try is the four SPI modes (Does clock idle high or low? Do we transfer on the full pulse, or on the half pulse?) - hardware often even supports two of them, and there's only one set which actually makes sense.
QSPI, on the other hand, is more of a wild-west. You need to run a bunch of chip-specific commands to enter QSPI mode, and there are quite a few possible variations for QSPI read commands, not to mention a lot of different timing requirements. Trying out all of them isn't really possible, hence the chip-specific boot2 segment.
Staying in SPI mode isn't really viable either because the application code is stored in the flash chip. To give an example, jumping to a random instruction would incur a 1280 ns read with a W25Q80BW flash chip operating in SPI mode (realistically x10 due to a lower safe clock frequency), whereas QSPI mode can reliably do that in as little as 125 ns. With the RP2040 running at 133MHz a 16-cycle delay for a random jump or a read from a data block is not too bad, but a 170 or even 1700-cycle delay is just way too much.
It's the DW_apb_ssi peripheral from Synopsys (https://www.synopsys.com/dw/ipdir.php?c=DW_apb_ssi).
May be I'm weird, but for me RP2040 was terrible chip for learning ARM. STM32 on the other hand just worked and I gradually learned to blink the chip, to write linker script, to write UART, to use C, to use CMSIS and so on. In the end I was able to write a commercial firmware with it.
I understand that if I would just use their SDK with cmake, that wouldn't be a problem, but I'm not going to use their SDK. I hate cmake and I need to understand everything from the ground up.
I think that at this moment I can grok this bootloader and write my own version of it, because I know much more about it, but it wouldn't serve its purpose as a chip for learning.
IMO that's a flawed approach: to throw infinitely complex tools onto a beginner. It's much easier to start simple, with just an assembler and may be linker. And a chip for beginners must not require those complex initialization procedures.
This chip is also incredibly complex with its two cores and PIO cores. It's absolutely cool thing, but it's absolutely not for beginners, it's for experienced engineers. I'd prefer something simple, like STM32, with built-in flash, but with proper documentation and without any compromises. Like flexible voltage source, on-board programmer, plenty of hardware blocks, not cheap price (because who cares if chip cost is $1 or $10 for hobby).
RP2040 documentation is superb, I must admit. That's what they did perfectly.
My experience was opposite of yours. I found RP2040 refreshing compared to the complexity of dealing with proprietary toolchains that other devices required for me to start working with their chips. Nearly every part of RP2040 was documented in great detail and usable exclusively with the tools I could find in Arch Linux repo (when using Linux) and Homebrew (when using Mac). I could drop down to assembly or move up to C++, or even Rust or Python depending on whether I wanted to tool around or just get things done.
Even more impressive was that I was able to use debugger with another RP2040 Pico acting as SWD debug probe (Google Picoprobe) which again worked the same across Mac and Linux with the software I already had (gdb) and saved me from buying yet another piece of JTAG hardware with questionable software support.
Oh, and every single software with RP2040, including UF2 boot-rom, second stage bootloader and examples are on Github, which allowed me to go as deep as I wanted and more importantly, just get on with what I needed to do when I wanted things to just work.
I've worked with uC on and off, but never I have worked with a uC that just worked with just worked with tools I already had. I now work exclusively with RP2040, even when I find other chips much more capable (ESP32 in this case). RP2040 allows me to futz around as long as I want, as deep or shallow as I have time on hand, plus when I stop futzing around, it allows me to just flash new ROM over USB and get on do what I /need/ to do.
Oh.. and I just love the USB mass-storage mode – no more custom flasher tools, just `cp blah.uf2 /mnt/RP2040/` and off I go. I can smoke it, but I can't brick it! Plus, when I need quick iteration I can just use PicoProbe and do `code - flash - debug - code` almost as fast as I can hit keyboard buttons.
RP2040 is a game changer for me!
I don't want to invest in one processor only to find out later that I needed USB2.0 instead of USB1.1, and then needing to read 500 pages of datasheets to move to a different platform.
Reading datasheets was nice at one point, but now it feels more like filling out tax forms.
Having worked quite a bit with both, I think the average beginner would find the rp2040's cmake based SDK more accessible than stm32cube, which I dislike immensely. The CircuitPython support is also really interesting for somebody who isn't a programmer but wants to experiment.
But if you're already an experienced programmer and want to roll your own stuff, I absolutely agree stm32 is a better way to go. This is a little example: https://github.com/jcalvinowens/ledboard
I will say, I think the generalized PIO engine the rp2040 has is incredible. I hope everybody starts doing that.
Once you get into ARM territory it inherently gets very complex very quickly. They are massive chips made of multiple IP blocks from different vendors which have been glued together. Full documentation easily gets into the thousands of pages. The RP2040 has excellent documentation, and even that is barely enough to be usable.
With the exception of a very small group of people at the design company, essentially nobody is hand-writing assembly. There's just no point: it's incredibly complicated, and it takes orders of magnitude longer than just using the provided SDK. This makes hand-writing it only an option for hobbyists: nobody wants to pay for their engineer to spend a lot of time doing it in a worse way. Turns out "I hate cmake" isn't a very good reason to waste tens of thousand of dollars in engineer-hours.
But even for the hobbyist the SDK is probably the better choice. The one provided for the RP2040 is quite well-made, and even if you hate cmake just copy/pasting its C code into your own cmake-less toy SDK probably makes more sense than reinventing the wheel yourself.
All this bootstrap sequencing is pretty typical for an ARM Cortex unit, and it's not as overburdened with options like, say, a TI Sitara. They're still unbricking with TFTP.
For $0.70 in onesies this is a pretty nice piece of silicon.
I feel the same, I didn't like Arduino's abstractions and how they hid what was actually going on. It has its appeals for people who don't care about the inner workings and just want to use a microcontroller to "quickly do something for which a microcontroller would be handy right now", but it won't get you much further than that, in my opinion.
Mainstream MCU manufacturers really skimp on it, even if you don't need Cortex-M4/7 to run a simple GUI you have to buy a whiz-bang part with huge pinout, very rich peripherals you won't need and a matching price tag for those.
It probably also helps that the RP2040 (and most Espressif chips too!) don't include any onboard flash. Adding a nontrivial amount of on-chip flash is quite expensive, so they just used that area budget for extra SRAM instead. If you want more than a few hundred K of flash you need to use an external chip anyways, so why bother with on-chip flash at all?
I'd like to try to find an example project where I could do something with a bare metal Pi Zero 2W.
In the end this is what really matters anyway; I'll take a fully documented complex chip over a black box whenever it matters.
Also while I appreciate everything that the RPi foundation does in their documentation efforts, I think they dont do a good job of indicating the difference between a lack of documentation and a lack of /public/ documentation. I would like to know a LOT more about the pcie interface between the Pi5 CPU and the custom peripheral controller for instance, but there's zero docs on it outside of kernel sources which are just a bunch of magic numbers and other undiscernable enchantments anyway.
On the big brothers, you have this odd CPU + GPU mish-mash and everything (including interrupt and mem layout) can look different depending on which one is currently running the show.
https://github.com/raspberrypi/pico-bootrom/blob/ef22cd8ede5...
And the explanation:
Is that a typo, or do I not understand this? Should it be "as long as RUN is high"? Because I assume that the RUN pin is active low, so as long as it is high, the chip will be held in reset?
> Global asynchronous reset pin. Reset when driven low, run when driven high. If no external reset is required, this pin can be tied directly to IOVDD.
RST pins tend to be active-low, which is the same thing. Perhaps Raspberry Pi decided to call it the "run" pin instead of the "reset" one to avoid possibly confusing hobbyists?
[0]: https://datasheets.raspberrypi.com/rp2040/rp2040-datasheet.p...
