RP2040 support? about edbg HOT 28 CLOSED

It should be pretty easy to do. All SPI devices have the same basic command set. I have not tried to connect the SWD part, so some work may be needed on that side.

I'll have a look at that later today. It should not be too hard.

from edbg.

I've implemented the programming too, but as expected it is very slow. I'll need to spend a bit of time optimizing it.

Also, an unexpected issue came up. To implement the multi-drop mode a debugger must support DAP_SWD_Sequence command, which is relatively new and only available in CMSIS-DAP version 1.2 or later.

I tried to use commercial debuggers (Atmel-ICE and MCU Link for now) to see if HS mode gives better performance, but none supported CMSIS-DAP version 1.2.

To check the version you can use a dummy command like "edbg -b -t samd11 -e". You don't need any devices connected. The output would be something like "Debugger: NXP Semiconductors MCU-Link CMSIS-DAP V2.263 US4D5CNRM1TS1 1.10 (SJ)". And "1.10" here is the protocol version. It must be at least "1.20"

from edbg.

You are fine with free-dap, it supports everything up to (and including) version 2.0. That's what I was using for development.

But if you can find a commercial debugger that has v1.20 or higher, I'd like to know. I'm surprised that MCU-Link does not support it. It is a good debugger otherwise.

from edbg.

I've committed RP2040 support. The testing was pretty minimal, I just tested with a copule standard Pico boards.
I have some custom boards that use a different flash device, but they don't break out SWD port in a convenient way, so this will have to wait.

Some numbers. On FS debugger programming 2 MB flash takes 3m37s. Verification/reading takes 1m10s. Just plain minimum data transfer over USB, SWD and SPI and flash erase/program operations would take about 1m30s.

On the HS debugger programming takes 51 seconds and verification takes 16 seconds. And it takes 30 seconds to just erases and program the flash, so it is pretty efficient.

from edbg.

Scope capture is not necessary, but the complete verbose output would be useful.

Especially pay attention to the version of the free-dap. CMSIS-DAP v2 is a relatively recent addition, and it is necessary here. Without it you would get invalid response error.

from edbg.

And also add "-b" to get verbose output.

from edbg.

There is no good way to retry the transfer. There are many things that can go wrong with unreliable connection, and some of them are unrecoverable at all. But this target is even more challenging, since it involves external flash, which has its own persistent state.

from edbg.

That would be awesome! Ping me if I can be of any help

from edbg.

I started looking at it, and it is a bit more complicated than I thought. RP2040 uses SWD v2 because it needs multi-drop support to get access to two cores on the same SWD interface.

There are not a lot of differences compared to v1, but it is also not as simple as adding a new target.

I'm still interested in supporting v2 anyway, so I'll work on it over the weekend and we'll see how far I can get.

from edbg.

Wow, ARM document has incorrectly calculated parity bit in the example. That was annoying.

But now I can access both cores (does not matter for programming, but may come in handy for debugging).

from edbg.

That's great news! If I can test something or help out, I'm happy to give a hand

from edbg.

No help needed for now. I've got reading and verification working, plus a lot of work on flash parameter discovery.

Writes should be done tomorrow. I've learned about SFDP for serial flash devices and got distracted by all the things I can extract from there :)

I'll probably ignore most of that discovered stuff and use reasonable assumptions about practical flash devices. But I'll at least use them for sanity checks.

from edbg.

I'm currently using free-dap, but I'll see if I can find a CMSIS-DAP with 1.20

from edbg.

Thank you very much @ataradov! I will try flashing my Raspberry Pi Pico with free-dap and report back any issues!

I'll close this ticket and reopen if issues arise.

from edbg.

I just added Nuvoton M484 platform to the free-dap. This is a USB HS device that is surprisingly cheap and available in a small low pin count package.

The HS numbers above come from the SAM E70 implementation, but the numbers for this one are basically the same.

from edbg.

Unfortunatley, I was not able to program my Raspberry Pi Pico using free-dap with the new edbg version. I did not receive any feedback from the microcontroller.

Coming from SAMD, I always needed to connect the nRST to get transfers working, even though SWD should would without reset. I have only connected GND, SWD and SWCLK to Raspberry Pi Pico (and a power supply), not nRST.

I assume RUN (RP2040 pin 26, Raspberry Pi Pico Pin 30) is nRST, but I'm unsure.

Did you need to connect nRST, if so to which pin?

from edbg.

What is the exact error message?

Does it come up as a hard drive if you reset (or power on) it while the button is held low? If that does not happen, then the board my be just dead.

There is no need for reset. My code does not even control it for this target.

from edbg.

What is the exact error message?

I will recapture the output and also take an oscilloscope reading. My free-dap adapter might be broken

Does it come up as a hard drive if you reset (or power on) it while the button is held low? If that does not happen, then the board my be just dead.

Yes, I can verify the pico board is working by flashing differnt blink examples using uf2

There is no need for reset. My code does not even control it for this target.

Ok, thanks for the information. I'll retry

from edbg.

I thought I had the most recent version of free-dap flashed. Will verify and come back here with full verbose output.

from edbg.

fyi I ordered another Raspberry Pi Pico in order to use the exact free-dap hardware and software you have used.

from edbg.

I did not use pico as a debugger. I used one of the SAM D11-based debuggers, but the firmware is the same.

from edbg.

I used one of my SAMD based debuggers, which uses a slightly modified firmware due to pin assignment. This should not matter, however I want to make sure.

from edbg.

What are the error messages you are getting?

from edbg.

I'lll post the exact error messages tomorrow, as I don't have the setup with me unfortunately

from edbg.

The exact output using two Raspberry Pi Pico is

$ sudo ./edbg -t rp2040 -r -f test.bin
Error: invalid response during transfer (count = 0/1, status = 7)

I will now make sure my wiring is correct, since I remember this as the same behaviour when having bad wiring

Update: Once every ~10 times I get Error: QSPI controller not found. So maybe just bad wiring?

from edbg.

Try adding "-c 100" to lower the clock. It looks like something is wrong with the electrical connection to the target.

from edbg.

@ataradov you were right! Verbose mode showed that the communication worked but failed after some time. Slowing down the clock made the transfer go longer but still failing

$> time sudo ./edbg -t rp2040 -c 100 -rbf test.bin
Debugger: Alex Taradov Generic CMSIS-DAP Adapter FA521D42 2.0.0 (SJ)
Clock frequency: 100.0 kHz
Target: RP2040 (Rev B2)
Flash size: 2 MB
Reading....................................................................................................Error: invalid response during transfer (count = 15/15, status = 7)

real	3m59,731s
user	0m0,650s
sys	0m2,594s

Since I'm fairly sure this has nothing to do with the software, but my hardware setup (since it fails at different stages of the transfer) I'm going to close this ticket.

Would it be possible to initiate a retransfer by edbg instead of bailing out?

from edbg.

I could have saved us so much trouble by soldering the wires from the get go

$> time sudo ./edbg -t rp2040 -rbf test.bin
Debugger: Alex Taradov Generic CMSIS-DAP Adapter EC4E962E 2.0.0 (SJ)
Clock frequency: 16.0 MHz
Target: RP2040 (Rev B2)
Flash size: 2 MB
Reading................................................................................................................................... done.

real	1m10,906s
user	0m0,638s
sys	0m3,433s

Thanks for your fast response time!

from edbg.