raspberrypi / debugprobe

Other
802 stars 216 forks source link

Can't debug with Windows VSCode #78

Closed ochamodev closed 1 year ago

ochamodev commented 1 year ago

After following the "Getting started with Raspberry Pi Pico" and following Appendix A, I still can't manage to debug the samples to test the the debugger.

Currently I'm getting these errors.

image image

Has anyone encontoured with this?

rgrr commented 1 year ago

You are using openocd 0.12. The rp2040 is currently best supported by openocd 0.11.

If you are using PlatformIO you should not use the "original" SDK, instead use the core from Max Gerhardt: https://arduino-pico.readthedocs.io/en/latest/platformio.html

This will also install the correct openocd (at least the last time I checked it)

ochamodev commented 1 year ago

Oh thanks for letting me know that. I will try the solutions you provided and let know if it works :]

ochamodev commented 1 year ago

After following the guide to use MSYS2 and building version openocd 0.11 now I get the following

image

Do you know what it means DAP init failed @rgrr ?

rgrr commented 1 year ago

Hmmm, ever tried a lower frequency?

You could also give this a try: https://github.com/rgrr/yapicoprobe/releases/tag/rg-1.12

ochamodev commented 1 year ago

Yeah @rgrr tried lower frecuency got the same error, gonna try this file you suggested. :]

ochamodev commented 1 year ago

I installed your solution @rgrr and got this when connecting vi putty to COM6

image

is it normal that the LED did not turn on?

Also after dragging the picoprobe uf2 file seems like it helped a bit more in recognizing the device and providing more info but still got the following error:

image

I tried with another RP2040 for debug probe and get the same message 🤔

I read I don't need zadig anymore for driver installation so I removed it, but wanted to ask if the pico should appear like this?

image image
rgrr commented 1 year ago

I installed your solution @rgrr and got this when connecting vi putty to COM6

That means, that the probe firmware is starting successfully. But the target is not detected. You should check cabling.

is it normal that the LED did not turn on?

No. The LED should always show something. What hardware are you using for the probe (pico/pico_w/pico_debug)? What's your target HW?

If there is no target detected, the LED should blink fast.

Also after dragging the picoprobe uf2 file seems like it helped a bit more in recognizing the device and providing more info but still got the following error: ...

As said: the probe does not detect your target HW. Have you checked your cabling? Does the target has power?

I read I don't need zadig anymore for driver installation so I removed it, but wanted to ask if the pico should appear like this?

Yes, that is correct. One CDC for probe debug output, one CDC for target debug output and one CDC for sigrok. Perhaps future releases will only reveal with one CDC and switch automatically between the modes.

ochamodev commented 1 year ago

The hardware I am using for probe is a pico and my target hardware is another pico too.

I have them wired them as the guide says. image

Here is a photo of my picos connected. wired_picos

And yes the target has power, here is a video after I plugged it.

https://user-images.githubusercontent.com/80477249/232247391-222f1314-7dae-455d-9e41-4e6dee5eaf5d.mp4

rgrr commented 1 year ago

Hmmm, actually it looks good as far as I can see from here. What I would do/try:

My test setup for verification:

image

Bottom of picture is the Pico probe, on top a Nordic PCA10056 (nRF52840 DK). And just three cables between probe and target. If the target is identified, the probe shows the following output:

[17:20:44.987499 159.587867] 0.000 (  0) - (II) SWD clk req   : 6000kHz = 168000kHz / (6 * (4 + 171/256)), eff : 5998kHz
[17:20:44.992962 0.005466] 0.004 (  4) - (II) ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
[17:20:44.996195 0.003233] 0.004 (  0) - (II) Target vendor     : NordicSemiconductor
[17:20:44.997899 0.001704] 0.005 (  1) - (II) Target part       : nRF52840
[17:20:44.998990 0.001091] 0.005 (  0) - (II) Flash             : 0x00000000..0x000fffff (1024K)
[17:20:45.000586 0.001597] 0.005 (  0) - (II) RAM               : 0x20000000..0x2003ffff (256K)
[17:20:45.002139 0.001553] 0.005 (  0) - (II) SWD frequency     : 6000kHz
[17:20:45.003197 0.001059] 0.005 (  0) - (II) SWD max frequency : 10000kHz
[17:20:45.004298 0.001101] 0.005 (  0) - (II) ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
[17:20:45.094201 0.089900] 0.105 (100) - (II) RTT_CB found at 0x20000028

The output varies if the target is an RP2040.

ochamodev commented 1 year ago

Ok, so I had the wrong image running on my probe and got a different error message.

image

I connected to the probe via UART and got the following.

image

https://user-images.githubusercontent.com/80477249/232411887-733352e9-b1d0-4f7b-bd8b-e2f54f354cd1.mp4

But I could not find where do you get that output you have at the end for the Nordic PCA10056.

Should I drop both elf and uf2 files on the target? Currently just dropped the elf file for blink project.

rgrr commented 1 year ago

...

But I could not find where do you get that output you have at the end for the Nordic PCA10056.

Should I drop both elf and uf2 files on the target? Currently just dropped the elf file for blink project.

Questions:

And one remark: 1MHz as SWD speed is a bad choice (undocumented feature which will disappear soon: this does not change the frequency). Use e.g. 1.1Mhz

There is still a problem in the communication between probe and target. Output should look like

hardy@ntbox:/etc/apache2$ openocd -f interface/cmsis-dap.cfg -f target/nrf52.cfg -c "adapter speed 2500"
Open On-Chip Debugger 0.12.0
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "swd". To override use 'transport select <transport>'.
adapter speed: 2500 kHz

Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : Using CMSIS-DAPv2 interface with VID:PID=0x2e8a:0x000c, serial=E6616407E3646B29
Info : CMSIS-DAP: SWD supported
Info : CMSIS-DAP: Atomic commands supported
Info : CMSIS-DAP: Test domain timer supported
Info : CMSIS-DAP: FW Version = 2.0.0
Info : CMSIS-DAP: Serial# = E6616407E3646B29
Info : CMSIS-DAP: Interface Initialised (SWD)
Info : SWCLK/TCK = 0 SWDIO/TMS = 0 TDI = 0 TDO = 0 nTRST = 0 nRESET = 0
Info : CMSIS-DAP: Interface ready
Info : clock speed 2500 kHz
Info : SWD DPIDR 0x2ba01477
Info : [nrf52.cpu] Cortex-M4 r0p1 processor detected
Info : [nrf52.cpu] target has 6 breakpoints, 4 watchpoints
Info : starting gdb server for nrf52.cpu on 3333
Info : Listening on port 3333 for gdb connections
ochamodev commented 1 year ago

sorry @rgrr I uploaded the wrong video, I updated my comment to have the correct one.

And, yes the LED is blinking, but after I plugged the LEDS it did not change after I connected the target to the probe.

rgrr commented 1 year ago

That looks much better. Stupid questions from my side, because there is really not a lot left:

ochamodev commented 1 year ago

hmmm yeah, soldering is ok, but wanted to make sure, and checked with a multimeter and both the target and probe give 0 volts on pin 4, I have a third RP2040 and also that one gives me 0 volts on the same port. Pin 5 gives me 3.3V.

I even changed the wires but got the asme result and yeah I connected both picos to the same PC haha 😓

Thinking that pin4 is maybe disabled by default?

rgrr commented 1 year ago

Hmmm, pin4 is SWCLK which is most of the time "0". Do you have an Oscilloscope? Or with some effort you could try sigrok with the pico probe as an osci (but unfortunately the required changes are not ready in libsigrok, so this would require a lot of fiddling).

Some things more to try:

I known, it is starting to get esoteric ;-)

If will try after work the connection with a pico board instead of the PCA10056.

rgrr commented 1 year ago

Here is my setup with two Pico boards, target is a Pico_W:

image

Output of the probe shows:

[20:45:21.626202 0.000003] 0.004 (  4) - (II) ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
[20:45:21.628013 0.001812] 0.004 (  0) - (II)                      Welcome to Yet Another Picoprobe v1.12-3590ff9
[20:45:21.629347 0.001335] 0.004 (  0) - (II) Features:
[20:45:21.629784 0.000438] 0.004 (  0) - (II)   [CMSIS-DAPv2] [CMSIS-DAPv1] [UART -> CDC] [sigrok CDC] [probe debug CDC] [DAPLink MSC]
[20:45:21.631319 0.001534] 0.005 (  1) - (II) ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
[20:45:21.632895 0.001577] 0.005 (  0) - (II) SWD clk req   : 2000kHz = 168000kHz / (6 * (14 + 0/256)), eff : 2000kHz
[20:45:21.634192 0.001297] 0.011 (  6) - (II) FLASH: Copying custom flash code to 0x20010000 (508 bytes)
[20:45:21.635307 0.001115] 0.025 ( 14) - (II) SWD clk req   : 15000kHz = 168000kHz / (6 * (1 + 222/256)), eff : 14995kHz
[20:45:21.636742 0.001434] 0.029 (  4) - (II) SWD clk req   : 16800kHz = 168000kHz / (6 * (1 + 171/256)), eff : 16786kHz
[20:45:21.638192 0.001451] 0.034 (  5) - (II) SWD clk req   : 2000kHz = 168000kHz / (6 * (14 + 0/256)), eff : 2000kHz
[20:45:21.639502 0.001309] 0.040 (  6) - (II) FLASH: Copying custom flash code to 0x20010000 (508 bytes)
[20:45:21.640614 0.001113] 0.050 ( 10) - (II) SWD clk req   : 15000kHz = 168000kHz / (6 * (1 + 222/256)), eff : 14995kHz
[20:45:21.641926 0.001312] 0.054 (  4) - (II) SWD clk req   : 16800kHz = 168000kHz / (6 * (1 + 171/256)), eff : 16786kHz
[20:45:21.643237 0.001312] 0.058 (  4) - (II) ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
[20:45:21.644745 0.001508] 0.058 (  0) - (II) Target vendor     : RaspberryPi
[20:45:21.645478 0.000732] 0.058 (  0) - (II) Target part       : RP2040
[20:45:21.646117 0.000640] 0.059 (  1) - (II) Flash             : 0x10000000..0x101fffff (2048K)
[20:45:21.647079 0.000962] 0.059 (  0) - (II) RAM               : 0x20000000..0x2003ffff (256K)
[20:45:21.648055 0.000975] 0.059 (  0) - (II) SWD frequency     : 15000kHz
[20:45:21.648731 0.000677] 0.059 (  0) - (II) SWD max frequency : 25000kHz
[20:45:21.649390 0.000659] 0.059 (  0) - (II) ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Openocd:

hardy@ntbox:/etc/apache2$ openocd -f interface/cmsis-dap.cfg -f target/rp2040.cfg -c "adapter speed 250"
Open On-Chip Debugger 0.12.0
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
adapter speed: 250 kHz

Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : Using CMSIS-DAPv2 interface with VID:PID=0x2e8a:0x000c, serial=E6614C775B333D35
Info : CMSIS-DAP: SWD supported
Info : CMSIS-DAP: Atomic commands supported
Info : CMSIS-DAP: Test domain timer supported
Info : CMSIS-DAP: FW Version = 2.0.0
Info : CMSIS-DAP: Serial# = E6614C775B333D35
Info : CMSIS-DAP: Interface Initialised (SWD)
Info : SWCLK/TCK = 0 SWDIO/TMS = 0 TDI = 0 TDO = 0 nTRST = 0 nRESET = 0
Info : CMSIS-DAP: Interface ready
Info : clock speed 250 kHz
Info : SWD DPIDR 0x0bc12477, DLPIDR 0x00000001
Info : SWD DPIDR 0x0bc12477, DLPIDR 0x10000001
Info : [rp2040.core0] Cortex-M0+ r0p1 processor detected
Info : [rp2040.core0] target has 4 breakpoints, 2 watchpoints
Info : [rp2040.core1] Cortex-M0+ r0p1 processor detected
Info : [rp2040.core1] target has 4 breakpoints, 2 watchpoints
Info : starting gdb server for rp2040.core0 on 3333
Info : Listening on port 3333 for gdb connections
Info : starting gdb server for rp2040.core1 on 3334
Info : Listening on port 3334 for gdb connections

I think you have to check your setup (again).

(checked openocd with high SWD frequencies as well: does work)

ochamodev commented 1 year ago

could you please try a lower SWD frequency, e.g. 100kHz?

I did that and got this error.

image

This was my configuration for that result.

Orange -> pin4 Yellow -> pin5

https://user-images.githubusercontent.com/80477249/232680443-c5f5cac2-8aa4-4ecc-a806-2492ec217914.mp4

although it is looking correctly: have you tried swapping the SW wires?

If I swap them to:

Orange -> pin5 Yellow -> pin4

https://user-images.githubusercontent.com/80477249/232680570-acdfd47a-e09b-4d2f-8eef-118ddaee64b4.mp4

And also using 100kHz the error is different.

image

have you exchanged your target device?

I have tried that now and well, and well, I get this error at first.

image

After swapping the cables like in the old probe, It worked. Now I wonder what is wrong with the other pico, I measured with the multimeter and it was reading it fine. I don't know what would be the cause xD but anyways the debugger now works.

https://user-images.githubusercontent.com/80477249/232680867-b3395164-15bd-4281-afa0-0aba18d3af39.mp4

https://user-images.githubusercontent.com/80477249/232681353-75e7ceb3-92b6-456e-a6ac-4d15cf763272.mp4

Output of the terminal:

image

do you have other targets than a pico board (like my PCA10056)

Unfortunately, no :/, I have only these devices.

have you tried to make a flying setup? I.e. pull the picos out of the breadboards and connect the wires directly to the pico pins

No, I haven't, but now that it works I am afraid to touch it hahaha.

I answered to all the questions, because I think it would be useful for others that might get the same error as me :) and also sorry for my late reply, I was working too 😅 .

You have saved me hahaha, thank you very much, I mean it :). You helped where my TA could not 😄 . Is there a way I could repay you for all my trouble :)?

rgrr commented 1 year ago

Hey, bravo! You can now increase SWD frequency ;-)

Do you have a wrap up of what went wrong? Because honestly I cannot see a systematic problem.

ochamodev commented 1 year ago

What would be the best freq? Based on your experience?🤔.

Well, as of now. No. I have no idea of what is not working. I might try swapping the targets again tomorrow, and see if I can find what went wrong. And leave the results here.

rgrr commented 1 year ago

Yes, that's a good idea.

Frequency? 8MHz works for me very nicely.

ochamodev commented 1 year ago

Sorry. I haven't posted for now. Currently under much work, but hopefully on the weekend I'll post my update.

ochamodev commented 1 year ago

Finally I got time to make this, here I leave a small setup guide for Windows users I made, so they can avoid all of the problems faced during the initial setup :) https://github.com/ochamodev/raspberry_pico_setup_guide

rgrr commented 1 year ago

Hey Otto, great. I will link in my docu to your guide. Can you close this issue then?

ochamodev commented 1 year ago

Sure, no problem :). Thanks for your help again.