On my system in Projects/rp2040/Archive/blink1 I have a simple LED blink demo coded in C. This is also "blink1" in my Github repository. The "make install" action in this project places blink.uf2 into /home/tom/pico, which is a handy place to find it and copy it to the pico.
I hold down the BOOTSEL button on my pico and click the reset button on my debug setup. This causes a "RP1-RP2" icon to appear on my linux desktop. I click this so it mounts, then I do:
cd /home/tom/pico cp blink.uf2 /run/media/tom/RPI-RP2As soon as I do this, the device unmounts and apparently the pico does a reset and starts running my code (and blinking).
openocd -f interface/cmsis-dap.cfg -c "adapter speed 5000" -f target/rp2040.cfg -s tclThen in another window:
telnet localhost 4444 reset halt resumeWhen I type "reset halt", I see:
[rp2040.core0] halted due to debug-request, current mode: Thread xPSR: 0xf1000000 pc: 0x000000ee msp: 0x20041f00 [rp2040.core1] halted due to debug-request, current mode: Thread xPSR: 0xf1000000 pc: 0x000000ee msp: 0x20041f00We will ignore core1 from now on. But why does it show the PC at 0xee? We expected to find it running at 0x1000xxxx in XIP addresses.
step [rp2040.core0] halted due to single-step, current mode: Thread xPSR: 0xf1000000 pc: 0x000000f0 msp: 0x20041f00We can also do this:
arm disassemble 0xee 8 0x000000ee 4873 ldr r0, [pc, #0x1cc] 0x000000f0 6801 ldr r1, [r0] 0x000000f2 2900 cmp r1, #0 arm disassemble 0x10000000 8 0x10000000 0000 movs r0, r0 0x10000002 0000 movs r0, r0 0x10000004 0000 movs r0, r0This is all quite perplexing. I wanted this to be a simple example of basic openOCD commands, not another puzzle.
One fellow used JTAG (in this case a Segger unit) to download code via the following command:
openocd -f interface/jlink.cfg -c "transport select swd" -c "adapter_khz 6000" -f target/rp2040.cfg -c "program blink.elf reset exit"The important bit here is the line "program blink.elf".
Typing "help flash" to openocd gets quite a long list of flash commands.
I try the following to read the flash:
flash banks #0 : rp2040.flash (rp2040_flash) at 0x10000000, size 0x00000000, buswidth 0, chipwidth 0 #1 : rp2040.alias (virtual) at 0x10000000, size 0x00000000, buswidth 0, chipwidth 0 flash read_bank 0 zz.zz Found flash device 'win w25q16jv' (ID 0x001540ef) RP2040 B0 Flash Probe: 2097152 bytes @0x10000000, in 32 sectors wrote 2097152 bytes to file zz.zz from flash bank 0 at offset 0x00000000 in 62.109898s (32.974 KiB/s)The second command took quite a long time, but ultimately did work.
flash read_bank 0 zz.2 0 2048 wrote 2048 bytes to file zz.2 from flash bank 0 at offset 0x00000000 in 0.061603s (32.466 KiB/s)This was essentially instantaneous. Then I dump the file, which only has 256 bytes that are interesting:
odx zz.2
00000000 0248 8546 00f0 44f8 fee7 0000 0010 0020 H F D
00000010 80b5 82b0 00af 8023 1b03 7b60 c046 7b68 # {` F{h
00000020 5a1e 7a60 002b fad1 c046 c046 bd46 02b0 Z z` + F F F
00000030 80bd 80b5 84b0 00af 7860 094b fb60 7a68 x` K `zh
00000040 fb68 1a60 074b fb60 c046 fb68 9b68 7a68 h ` K ` F h hzh
00000050 1340 fad0 c046 c046 bd46 04b0 80bd c046 @ F F F F
00000060 00f0 0040 00c0 0040 80b5 84b0 00af 7860 @ @ x`
00000070 3960 064b fb60 3a68 f968 7b68 db00 cb18 9` K `:h h{h
00000080 0433 1a60 c046 bd46 04b0 80bd 0040 0140 3 ` F F @ @
00000090 80b5 82b0 00af 2020 fff7 cbff 0521 1920 !
000000a0 fff7 e2ff d023 1b06 7b60 7b68 8022 9204 # {`{h "
000000b0 5a62 7b68 8022 9204 5a61 fff7 a9ff 7b68 Zb{h " Za {h
000000c0 8022 9204 9a61 fff7 a3ff c046 f1e7 c046 " a F F
000000d0 0000 0000 0000 0000 0000 0000 0000 0000
000000e0 0000 0000 0000 0000 0000 0000 0000 0000
000000f0 0000 0000 0000 0000 0000 0000 cbe6 55c7 U
00000100 ffff ffff ffff ffff ffff ffff ffff ffff
00000110 ffff ffff ffff ffff ffff ffff ffff ffff
I can compare this to my disassembly, the first part of which
looks like this:
10000000: 10000000: 4802 ldr r0, [pc, #8] @ (1000000c ) 10000002: 4685 mov sp, r0 10000004: f000 f844 bl 10000090
mdw 0 32 0x00000000: 20041f00 000000ef 00000035 00000031 0201754d 00c8007a 0000001d 88022300 0x00000020: d003429a 30048843 d1f74291 47701c18 e7fdbf30 f00046f4 489ef805 60012100 0x00000040: 46e76041 2100489c 600143c9 47706041 952d5481 00001e09 20294328 30323032 0x00000060: 73615220 72656270 50207972 72542069 6e696461 744c2067 33500064 335202d9 mdw 0x10000000 32 0x10000000: 46854802 f844f000 0000e7fe 20001000 b082b580 2380af00 607b031b 687b46c0 0x10000020: 607a1e5a d1fa2b00 46c046c0 b00246bd b580bd80 af00b084 4b096078 687a60fb 0x10000040: 601a68fb 60fb4b07 68fb46c0 687a689b d0fa4013 46c046c0 b00446bd 46c0bd80 0x10000060: 4000f000 4000c000 b084b580 6078af00 4b066039 683a60fb 687b68f9 18cb00dbNote in the above that the dump at 0x10000000 (the XIP address) matches the rom contents once you sort out byte order issues.
The dump at 0x0 matches the bootrom (as it should). A hex dump of the bootrom is like so:
00000000 001f 0420 ef00 0000 3500 0000 3100 0000 5 1 00000010 4d75 0102 7a00 c800 1d00 0000 0023 0288 Mu z # 00000020 9a42 03d0 4388 0430 9142 f7d1 181c 7047 B C 0 B pG 00000030 30bf fde7 f446 00f0 05f8 9e48 0021 0160 0 F H ! ` 00000040 4160 e746 9c48 0021 c943 0160 4160 7047 A` F H ! C `A`pG 00000050 8154 2d95 091e 0000 2843 2920 3230 3230 T- (C) 2020 00000060 2052 6173 7062 6572 7279 2050 6920 5472 Raspberry Pi Tr 00000070 6164 696e 6720 4c74 6400 5033 d902 5233 ading Ltd P3 R3
On top of that, the code is running just fine and the LED blinks just as it should.
I search on this and find that this PC value is "well known" and indicates some kind of bug in the version of OpenOCD I am using. Perhaps it isn't a bug, but the general advice is to find the Raspberry Pi specific fork of OpenOCD
Some systems provide this in a package named "openocd-raspberrypi", but not Fedora apparently. I fetch this, build it, and remove the fedora version before typing "make install". Then I try my original command:openocd -f interface/cmsis-dap.cfg -c "adapter speed 5000" -f target/rp2040.cfg -s tclIt tells me "The specified adapter driver was not found (cmsis-dap)".
Then I try the following, and get a different error:
openocd -f interface/picoprobe.cfg -c "adapter speed 5000" -f target/rp2040.cfg -s tclIt tells me "Error: Can't find interface/picoprobe.cfg". Note that in once case it cannot find the driver, and in the other case it cannot find the specified file.
locate cmsis-dap.cfg /usr/local/share/openocd/scripts/interface/cmsis-dap.cfg locate picoprobe.cfg /Projects/rp2040/dwelch/picoprobe.cfgSo, there is no picoprobe.cfg in any "official" location, but the "make install" for the Raspberry Pi openocd put the files into /usr/local. (openocd itself is in /usr/local/bin). This would allow me to install openocd from the Fedora packages nicely alongside of this, but to avoid confusion, I do this:
cd /usr/local/bin mv openocd openocd-rpiNext I copy picoprobe.cfg to my current directory and try this:
openocd-rpi -f picoprobe.cfg -c "adapter speed 5000" -f target/rp2040.cfg -s tclNow it tells me that it cannot find the picoprobe adapter driver.
What the heck? It seems like the raspberry pi build contains neither the picoprobe driver nor the cmsis-dap driver. I did explicitly ask for the picoprobe driver, so how did that go wrong? See the end of this writeup:
The state of things with openocd and the rp2040 seems to be nothing short of a disaster. It would be nice if this worked, but I don't have the time or inclination to sort out the mess the openocd project is in.
Tom's software pages / tom@mmto.org