RP2040 + Raspberry Pi Pico board

[newbrain]

I'm about to create PR for a ThreadX/Azure RTOS plugin (probably today or tomorrow), but, in the meantime, I've ordered a couple of the new Pico boards.

If there's any interest, I can start some work to add the RP2040 MCU to the built in targets, and the Pico to board id list (possibly with its new blinky binary).

The target is has a bootrom, and possibly a 2nd stage bootloader to setup the external flash, flash algorithms are in rom too, so that should not be a terribly complicated task.
I can probably get inspiration from the RPi openocd fork.

Not having received them yet, this is only preliminary work (i.e.: I cannot test until I have the board).

[flit]

I've got some Pico boards on order too. 😄 They should be here on Monday. My goal is to extensively support the Pico in pyocd.

There is one complication for quickly supporting the RP2040. Section 2.3.4 in the datasheet describes the DAP structure. It has three DPs, one for each M0+ core and a "Rescue DP", connected via multidrop SWD. The Rescue DP is not connected to any APs and its CDBGPWRUPREQ signal is misused as a reset-and-tell-ROM-to-halt request. This is definitively not the right way to do it, and makes multicore debug overly complex and potentially very slow. (There should be a single DP with one AHB-AP per M0+, and a proprietary AP with a single register, plus ID reg, to control the rescue signal.)

The use of multidrop SWD is a problem only because pyOCD doesn't support it yet since there hasn't been a need for it. (It has never even been on the roadmap.)

Given that, we should start with single-core RP2040 and flash programming support, and then work on multidrop support.

Normally supporting devices with a boot ROM can be tricky because vendors like to disable debug while the ROM is executing startup (often for part configuration such as phantoming, i.e., setting the available memory sizes and/or features based on configured part number). But in this case the ROM is open source and debug is probably never disabled.

We can use the FlashAlgo project to quickly build the flash algo using the ROM APIs.

(One of the problems with multidrop SWD is that there is no way to automatically discover available DPs. You have to know the target ID in advance. This should be possible to work around for the RP2040 though.)

cc @mbrossard

[newbrain]

Ah yes, I had noticed something strange about that, but not being expert at all in this DP/AP intricacies, I did not give it much weight.
I only did some work to bring the MSP432 and MKE04 to the Blackmagic Probe. I'll have to study a bit of Arm docs.

My expectation is that 99% of the people will use only one core...

But in this case the ROM is open source and debug is probably never disabled.

Yes it would seem so from some description in the datasheet (a seriously lacking one: no real timing specs, just the max clock frequency...), where they are nagging that some debugger will not set HW breakpoints, so a RAM trampoline is needed to call the ROM and break.

You have to know the target ID in advance. This should be possible to work around for the RP2040 though.)

What are the practical implications? The need to specify the target on the command line?

All in all a quite weird chip: double M0+, a bizarre (but probably fun!) programmable IO, only one timer though 64 bit, but clocked at 1 µs (half million years rollover 😂) and various other oddities...

[flit]

I'll have to study a bit of Arm docs.

This blog has a good introduction to the ADI architecture.

where they are nagging that some debugger will not set HW breakpoints, so a RAM trampoline is needed to call the ROM and break.

I missed that!

What are the practical implications? The need to specify the target on the command line?

The need to specify the target on the command line will follow normal pyocd rules. Meaning, it depends on whether the debug probe reports the connected target (so basically a target-specific build of DAPLink).

If pyocd defaults to the cortex_m target, then it will only see one M0+. (Because it can't discover the other DPs.)

Actually, it's worse than that… If a debugger disconnected with the second core or Rescue DP selected, then pyocd would only see the selected DP/core. Or in the case of the Rescue DP, nothing.

[flit]

Someone has already written an FLM-compatible flash algo in Rust: https://github.com/rp-rs/flash-algo

That's one piece of the work already done. 😄

[flit]

First connect: the Pico's ROM bootloader mass storage volume was mounted, connecting pyocd via pyocd cmd -v -tcortex_m found the DP, and the mass storage volume disappeared. My guess is that the Rescue DP is selected by default. Definitely not ideal… we'll have to implement at least selection of the first core's DP, but that should be fairly straightforward.

Log:

0000602:INFO:board:Target type is cortex_m
0000619:INFO:dap:DP IDR = 0x0bc12477 (v2 MINDP rev0)
Exception while initing board: No cores were discovered!

[flit]

Created the branch where I'll be adding RP2040 support: https://github.com/flit/pyOCD/tree/feature/rp2040
Feel free to create pull requests against this branch.

I haven't gotten the flash algo to build yet. It requires a nightly version of cargo, and I'm having trouble getting that and the thumbv6m-none-eabi toolchain installed.

[therealprof]

I haven't gotten the flash algo to build yet. It requires a nightly version of cargo, and I'm having trouble getting that and the thumbv6m-none-eabi toolchain installed.

rustup toolchain install nightly
rustup target add --toolchain nightly thumbv6m-none-eabi
cargo install cargo-binutils
cargo +nightly build

@Dirbaio
The build.sh is not particularly great since it assumes that nightly is the default toolchain and the LLVM tools are installed separately (or made available via cargo-binutils).

[Dirbaio]

Agreed. PRs welcome :)

[flit]

Some progress has been made on my flit:feature/rp2040 branch. (PRs against this branch are welcome.)

The pyocd.target.builtin.target_rp2040.RP2040 target class has been created, with a memory map and flash algo. It modifies the init sequence to send the target selection sequence to select core 0, but that isn't working yet. (The whole thing is implemented, but it's just not working; need to break out the logic analyzer. 😄)

To generate the target selection sequence, an swd_sequence() method and corresponding SWD_SEQUENCE capability were added to the DebugProbe API. Currently implemented only for CMSIS-DAP, and is pretty much a direct interface to the DAP_SWD_Sequence command. I need to review other probes to see if it can be generalized.

[Dirbaio]

From a quick look at the code I think you're missing the "dormant-to-swd" sequence before targetsel. That one is new for SWDv2 too.

https://github.com/rp-rs/probe-rs/blob/f37dbf7f944d2f9e915b7f9995f3ea2712d59619/probe-rs/src/probe/daplink/mod.rs#L486-L490

[flit]

From reading the ADI docs (IHI0074C Debug Interface v6.0 Architecture Specification, section B4.3.4), it seems like moving to dormant mode first is not required. The RP2040 uses the SW-DP (not SWJ-DP with JTAG support) so no "X to SWD" sequence should be supported.

[Dirbaio]

🤷 not sure about the spec but I can confirm the chip doesn't reply if you don't do dormant-to-swd first.

As I understand it, initially all the DPs are in "dormant" state. On dormant-to-swd, all DPs change to "active" state. On targetsel, all DPs that don't match go back to "dormant" state, so you're left with just the one you want in "active" state.

[flit]

Interesting. Thanks for confirming the actual behaviour!

[flit]

Fwiw, I found the section in the ADIv6 spec that documents the initial dormant state: B5.3.1 "Using the dormant state outside of SWJ-DP".

Turns out it's only the SW-DP v2 or v3 that starts in dormant state. The initial state for SWJ-DP is JTAG Test-Logic-Reset. (Of course, SW[J]-DPv1 doesn't support dormant mode.)

[flit]

The RP2040 target on my flit:feature/rp2040 branch is working now for core 0. Flash programming seems to work fine.

There are a few things I'd like to clean up before merging. (The CI servers are also still down due to the blackouts in Austin from the winter storms.)

[newbrain]

Great!
Kudos, and thanks!
As I wrote above, I needed to know more about the AP/DP intricacies, so I thought a good way was to write the support for the Picoprobe.
As it is the most basic possible adapter (in practice, bit banging with a USB interface), I had to read quite a bit. Good for me.
I will be making a PR in the coming days, if there's any interest.
The code is working (this commit, later ones are WIP) but needs to be cleaned up and some logging added, I'm able to flash, read and write memory, and use breakpoints (tested for now with a STM32L476).
It's no speed daemon, but that's due to the Picoprobe USB handling - with some (optional) shortcuts I get about 8 kB/s flashing.

[flit]

@newbrain's picoprobe support (Thanks again! 🥇) has been merged into my feature/rp2040 branch, since it supports the newly added swd_sequence() API that is required to perform the target selection sequence.

In the initial PR with Pico support, I'm going to add two separate targets for the RP2040, for the two cores. So you'll be able to debug either core, but not both simultaneously. I'm also planning some architectural changes to cleanly support multi-drop SWD and multiple DPs.

[newbrain]

but not both simultaneously

I see it quite hard, given the multiple DP structure.
Am I right in thinking it would be quite message intensive*, to continuously switch active DP to poll the two cores (not to speak about responsiveness), or it's just my limited understanding?

*Wake one DP, poll/write/read, make it dormant again, rinse and repeat with the other core...

[flit]

Am I right in thinking it would be quite message intensive

Sort of. It requires a line reset (51 cycles), 2 idle cycles, and a write to DP_TARGETSEL (48 cycles) = 101 cycles. This can be done in one CMSIS-DAP packet. So the target selection sequence itself is not too bad. Thankfully you don't have to go through dormant mode. The actual overhead depends on how frequently you have to switch cores (obviously). Polling both cores would be about the worst case.

Section B4.3.4 of the Arm ADI v5.2 or v6 specification documents the target selection protocol.

[flit]

Update: RP2040 support (#1083) has been merged in.

There are three targets:

• rp2040_core0
• rp2040_core1
• rp2040, an alias for core0

The plan is to release a new pyocd version 0.30.0 this weekend.