pyocd and keil not work, but openocd is ok

[PR2403]

Hi,

I have a pico clone board (the purple ones) that I can flash with the official picoprobe firmware without any problem. I want to try yapicoprobe (mainly to have systemview).

Using the latest release firmware (yapicoprobe-0120-pico-f726bca.uf2), pyocd

pyocd flash  -t stm32f103ve ./dr_freertos_test.hex
0000980 I Loading C:\Users\admin\Desktop\weact\dr_freertos_test\MDK-ARM\dr_freertos_test\dr_freertos_test.hex [load_cmd]
[---|---|---|---|---|---|---|---|---|----]
[0001160 E Error during board uninit: [session]
0001160 E Probe error during disconnect: [session]
0001160 C DAP_TRANSFER response error: response is for command 00 [__main__]

debug cdc

 =================================== DAPv2 connect target, host pyOCD with single big buffer, buffer: 1x1024bytes
 0.042 ( 42) - (II) SWD clk req   : 1000kHz = 192000kHz / (6 * (32 + 0/256)), eff : 1000kHz

until I goback to probe v1.03, openocd\pyocd\keil all work

[rgrr]

Hello,

does that mean, that 1.04 also does not work or not tested?

• what does pyocd gdb -vvvvv output?
• what is the voltage level of the STM32?
• did you try to reduce probes CPU frequency? (via terminal, see https://github.com/rgrr/yapicoprobe/tree/master?tab=readme-ov-file#runtime-configuration-of-probe-parameters)

[PR2403]

hi

pyocd gdb -vvvvv output

0000409 D Project directory: C:\Users\admin\Desktop\weact\dr_freertos_test\MDK-ARM\dr_freertos_test [session]
0000461 D Project directory: C:\Users\admin\Desktop\weact\dr_freertos_test\MDK-ARM\dr_freertos_test [session]
0000476 D CMSIS-DAP v2 probe B5C086170E375453: protocol version 2.1.2 [dap_access_cmsis_dap]
0000478 D Using default Cortex-M memory map (no memory map supplied) [coresight_target]
0000478 I Target type is cortex_m [board]
0000505 D Board: Generic Generic [cmsis_dap_probe]
0000505 D Target: Generic cortex_m [cmsis_dap_probe]
0000707 D Running task load_svd [sequencer]
0000708 D Running task pre_connect [sequencer]
0000708 D Running task dp_init [sequencer]
0000708 D Running task lock_probe [sequencer]
0000708 D Running task get_probe_capabilities [sequencer]
0000708 D Running task connect [sequencer]
0000710 D Default wire protocol selected; using SWD [dap]
0000711 D Sending deprecated SWJ sequence to select SWD [swj]
0000712 I DP IDR = 0x1ba01477 (v1 rev1) [dap]
0000712 D Running task clear_sticky_err [sequencer]
0000712 D Running task power_up_debug [sequencer]
0000713 D Running task check_version [sequencer]
0000713 D Running task unlock_probe [sequencer]
0000713 D Running task unlock_device [sequencer]
0000713 D Running task create_discoverer [sequencer]
0000713 D Running task discovery [sequencer]
0000713 D Running task find_aps [sequencer]
0000716 D Running task create_aps [sequencer]
0000716 D Running task create_ap.0 [sequencer]
0000718 D AHB-AP#0 default HPROT=3 HNONSEC=0 [ap]
0000718 D AHB-AP#0 implemented HPROT=3 HNONSEC=0 [ap]
0000719 I AHB-AP#0 IDR = 0x14770011 (AHB-AP var1 rev1) [discovery]
0000719 D Running task find_components [sequencer]
0000719 D Running task init_ap.0 [sequencer]
0000722 I AHB-AP#0 Class 0x1 ROM table #0 @ 0xe00ff000 (designer=020:ST part=410) [rom_table]
0000725 I [0]<e000e000:SCS v7-M class=14 designer=43b:Arm part=000> [rom_table]
0000726 I [1]<e0001000:DWT v7-M class=14 designer=43b:Arm part=002> [rom_table]
0000727 I [2]<e0002000:FPB v7-M class=14 designer=43b:Arm part=003> [rom_table]
0000728 I [3]<e0000000:ITM v7-M class=14 designer=43b:Arm part=001> [rom_table]
0000730 I [4]<e0040000:TPIU M3 class=9 designer=43b:Arm part=923 devtype=11 archid=0000 devid=ca1:0:0> [rom_table]
0000732 I [5]<e0041000:ETM M3 class=9 designer=43b:Arm part=924 devtype=13 archid=0000 devid=0:0:0> [rom_table]
0000732 D Running task create_cores [sequencer]
0000732 D Creating SCS component [discovery]
0000733 D selected core #0 [soc_target]
0000735 I CPU core #0: Cortex-M3 r1p1, v7.0-M architecture [cortex_m]
0000736 D Running task create_components [sequencer]
0000736 D Creating DWT component [discovery]
0000737 I 4 hardware watchpoints [dwt]
0000738 D Creating FPB component [discovery]
0000739 I 6 hardware breakpoints, 4 literal comparators [fpb]
0000739 D fpb has been disabled [fpb]
0000739 D Creating ITM component [discovery]
0000741 D Creating TPIU component [discovery]
0000742 D Running task check_for_cores [sequencer]
0000742 D Running task halt_on_connect [sequencer]
0000742 D halting core 0 [cortex_m]
0000743 D Running task post_connect [sequencer]
0000743 D Running task post_connect_hook [sequencer]
0000743 D Running task create_flash [sequencer]
0000743 D Running task notify [sequencer]
0000744 D Setting vector catch to 0x00000001 [cortex_m]
0000750 I Semihost server started on port 4444 (core 0) [server]
0000883 I GDB server started on port 3333 (core 0) [gdbserver]

3.3V on stm32 but powered from other source, only gnd swdio swclk is connected

reduce to 96MHz, same problem

[PR2403]

emmm, I don't know why, but probe can't reconize stm32 now, even with official picoprobe firmware IO broke?

[rgrr]

hi

pyocd gdb -vvvvv output

0000409 D Project directory: C:\Users\admin\Desktop\weact\dr_freertos_test\MDK-ARM\dr_freertos_test [session]
0000461 D Project directory: C:\Users\admin\Desktop\weact\dr_freertos_test\MDK-ARM\dr_freertos_test [session]
...
0000744 D Setting vector catch to 0x00000001 [cortex_m]
0000750 I Semihost server started on port 4444 (core 0) [server]
0000883 I GDB server started on port 3333 (core 0) [gdbserver]

3.3V on stm32 but powered from other source, only gnd swdio swclk is connected

reduce to 96MHz, same problem

Thanks... do I understand correctly, that "gdb" is working while "flash" does not? Even with the newest version?

[rgrr]

You wrote in a perhaps edited comment (got it via email), that "1.04 all work well". So if I understand correctly with 1.04 also "pyocd flash" worked with the STM? If you have some time, could you please try to find out which probe firmware introduced the bug?

[PR2403]

my pico pin gp2 and gp3 is broken. I'm using your latest branch and change the pin. I will buy another one to test. btw, is there some special settings for the systemview on target? I try to let the probe systemview function work, jlink is ok systemview says Did not record SystemView TRACE START event, yet. also, if I want systemview redirect to CDC, just change OPT_CDC_SYSVIEW ? the RTT works well now, thanks for this probe

[PR2403]

there is a bug when I fix the RTT_CB address, probe wil not redirect to CDC even it detect the buffer address

[rgrr]

there is a bug when I fix the RTT_CB address, probe wil not redirect to CDC even it detect the buffer address

What do you mean with "fix the RTT_CB"?

[rgrr]

... btw, is there some special settings for the systemview on target? I try to let the probe systemview function work, jlink is ok systemview says Did not record SystemView TRACE START event, yet....

Have you read https://github.com/rgrr/yapicoprobe?tab=readme-ov-file#systemview ?

[PR2403]

Manually set rtt_cb address in linker in keil just edit .sct file

---Original--- From: "Hardy @.> Date: Tue, Jul 23, 2024 21:04 PM To: @.>; Cc: @.**@.>; Subject: Re: [rgrr/yapicoprobe] pyocd and keil not work, but openocd is ok(Issue #112)

there is a bug when I fix the RTT_CB address, probe wil not redirect to CDC even it detect the buffer address

What do you mean with "fix the RTT_CB"?

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

[PR2403]

yes I have read it. I can see systemview connect info on debug cdc but nothing on systemview with jlink it's fine. so I don't know if I have missed something

---Original--- From: "Hardy @.> Date: Tue, Jul 23, 2024 21:06 PM To: @.>; Cc: @.**@.>; Subject: Re: [rgrr/yapicoprobe] pyocd and keil not work, but openocd is ok(Issue #112)

... btw, is there some special settings for the systemview on target? I try to let the probe systemview function work, jlink is ok systemview says Did not record SystemView TRACE START event, yet....

Have you read https://github.com/rgrr/yapicoprobe?tab=readme-ov-file#systemview ?

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

[rgrr]

Manually set rtt_cb address in linker in keil just edit .sct file […]

Hmmm... which address? The probe is searching just a specific range output on its debug console. This range can as far as I remember changed via probe config.

[rgrr]

yes I have read it. I can see systemview connect info on debug cdc but nothing on systemview with jlink it's fine. so I don't know if I have missed something...

The probe expects sysview output on RTT channel 1. What does the probe debug output say?

[PR2403]

Hmmm... which address? The probe is searching just a specific range output on its debug console. This range can as far as I remember changed via probe config.

0x2000ff88 the probe detect the rtt_cb and buffer address, I see the info on debug cdc, but nothing output

[PR2403]

The probe expects sysview output on RTT channel 1. What does the probe debug output say?

click run in systemview, debug output "systemview connect", and then nothing happened click stop,debug output "systemview disconnect" I saw the channel 1 buffer address on debug output

[PR2403]

Hmmm... which address? The probe is searching just a specific range output on its debug console. This range can as far as I remember changed via probe config.

0x2000ff88 the probe detect the rtt_cb and buffer address, I see the info on debug cdc, but nothing output

9.618 (904) - (II) ---- RTT_CB found at 0x2000ff88
9.620 (  2) - (II)      rtt_check_channel_from_target: 0 20004DD4  1024     0    25
9.622 (  2) - (II)      rtt_check_channel_to_target  : 0 20004C14     8     0     0
9.623 (  1) - (II)      rtt_check_channel_from_target: 1 20004814  1024     0     0
 9.626 (  3) - (II) ---- RTT_CB at 0x2000ff88 seems to be inactive, searching again...
10.228 (602) - (II) searching RTT_CB in 0x20000000..0x2003ffff, prev: 0x00000000
11.132 (904) - (II) ---- RTT_CB found at 0x2000ff88
11.134 (  2) - (II)      rtt_check_channel_from_target: 0 20004DD4  1024     0    30
11.136 (  2) - (II)      rtt_check_channel_to_target  : 0 20004C14     8     0     0
11.137 (  1) - (II)      rtt_check_channel_from_target: 1 20004814  1024     0     0
11.140 (  3) - (II) ---- RTT_CB at 0x2000ff88 seems to be inactive, searching again...
11.742 (602) - (II) searching RTT_CB in 0x20000000..0x2003ffff, prev: 0x00000000

0x20004C14 is channel 1 down buffer address not channel 0

[PR2403]

0x20004C14 is channel 1 down buffer address not channel 0

Hi,I found why systemview notwork I changed the RTT max channel num setting, default is 3, I changed it to 2. I changed back, systemview worked

[rgrr]

I'm a little bit confused now: what is working and what is not working?

[PR2403]

pyocd always not work and if I change rtt settings on target, rtt and systemview not work SEGGER_RTT_MAX_NUM_DOWN_BUFFERS SEGGER_RTT_MAX_NUM_UP_BUFFERS default it is 3, I changed it to 2

[PR2403]

sorry for confusing, maybe I should create another issue for rtt settings problem

[rgrr]

good idea. So coming back to the STM / pyocd topic:

• openocd works with all probe firmware versions?
• pyocd only works with 1.03?

Halfway correct?

[PR2403]

can't test now, my pico gp2\gp3 pin is broken I will buy some more for testing

[PR2403]

1.20-1.11 pyocd not work 1.10 all work

[rgrr]

Thanks... quick compare between 1.10 and 1.11 shows almost nothing relevant - except parameters for pyocd parameters on CMSIS-DAP.

Now I'm wondering which version of pyocd you are actually using?

[PR2403]

0.36.0

[rgrr]

can you compile the probe firmware?

[PR2403]

yes

[rgrr]

great...

So replace in src/cmsis-dap/dap_server.c

#define _DAP_PACKET_SIZE_PYOCD      1024

with

#define _DAP_PACKET_SIZE_PYOCD      128

and recheck.

[rgrr]

I had this question above: pyocd gdb works, while pyocd flash does not?

[PR2403]

So,change to 128, pyocd work I just try pyocd gdb, not connect to it anyway thanks for help btw, I bought 2 pico clone this time, one is complete not work, even with offical probe firmware(cdc is worked). maybe chip's physical condition？

[rgrr]

Hey great (correctly understood that flashing works with 128?). I'm wondering if this is a bug in pyocd. Could you please try 256 and 512?

Concerning your two electronics: if it does not work at all, than it is most likely broken ;-) send it back.

[PR2403]

pyocd works with 256 and 512

[rgrr]

Great... thank you for finding this out. In the next version I will revert back to 512 packet size.