Control block not found when using rtt with pyocd 0.35.0

[yannroth]

After upgrading to pyocd 0.35.0, rtt is not running anymore. I am testing on custom board with an nrf52832. Here is

(pyocd) yann@~/venv$ pyocd --version
0.35.0
(pyocd) yann@~/venv$ pyocd rtt -t nrf52
0000936 I Target type is nrf52 [board]
0001089 I DP IDR = 0x2ba01477 (v1 rev2) [dap]
0001165 I AHB-AP#0 IDR = 0x24770011 (AHB-AP var1 rev2) [discovery]
0001165 I AP#1 IDR = 0x02880000 (AP var0 rev0) [discovery]
0001166 I NRF52832 not in secure state [target_nRF52]
0001172 I AHB-AP#0 Class 0x1 ROM table #0 @ 0xe00ff000 (designer=244 part=006) [rom_table]
0001180 I [0]<e000e000:SCS v7-M class=14 designer=43b:Arm part=00c> [rom_table]
0001185 I [1]<e0001000:DWT v7-M class=14 designer=43b:Arm part=002> [rom_table]
0001189 I [2]<e0002000:FPB v7-M class=14 designer=43b:Arm part=003> [rom_table]
0001192 I [3]<e0000000:ITM v7-M class=14 designer=43b:Arm part=001> [rom_table]
0001197 I [4]<e0040000:TPIU M4 class=9 designer=43b:Arm part=9a1 devtype=11 archid=0000 devid=ca1:0:0> [rom_table]
0001202 I [5]<e0041000:ETM M4 class=9 designer=43b:Arm part=925 devtype=13 archid=0000 devid=0:0:0> [rom_table]
0001204 I CPU core #0 is Cortex-M4 r0p1 [cortex_m]
0001205 I FPU present: FPv4-SP-D16-M [cortex_m]
0001208 I This appears to be an nRF52832 QFAA E1 [target_nRF52]
0001209 I 4 hardware watchpoints [dwt]
0001212 I 6 hardware breakpoints, 4 literal comparators [fpb]
0005943 C Control block not found [__main__]

When running on pyocd 0.34.3, there is no issue:

(pyocd) yann@~/venv$ pyocd --version
0.34.3
(pyocd) yann@~/venv$ pyocd rtt -t nrf52
0000933 I Target type is nrf52 [board]
0001083 I DP IDR = 0x2ba01477 (v1 rev2) [dap]
0001100 I AHB-AP#0 IDR = 0x24770011 (AHB-AP var1 rev2) [ap]
0001158 I AP#1 IDR = 0x02880000 (AP var0 rev0) [ap]
0001158 I NRF52832 not in secure state [target_nRF52]
0001164 I AHB-AP#0 Class 0x1 ROM table #0 @ 0xe00ff000 (designer=244 part=006) [rom_table]
0001172 I [0]<e000e000:SCS v7-M class=14 designer=43b:Arm part=00c> [rom_table]
0001177 I [1]<e0001000:DWT v7-M class=14 designer=43b:Arm part=002> [rom_table]
0001181 I [2]<e0002000:FPB v7-M class=14 designer=43b:Arm part=003> [rom_table]
0001185 I [3]<e0000000:ITM v7-M class=14 designer=43b:Arm part=001> [rom_table]
0001190 I [4]<e0040000:TPIU M4 class=9 designer=43b:Arm part=9a1 devtype=11 archid=0000 devid=ca1:0:0> [rom_table]
0001195 I [5]<e0041000:ETM M4 class=9 designer=43b:Arm part=925 devtype=13 archid=0000 devid=0:0:0> [rom_table]
0001196 I CPU core #0 is Cortex-M4 r0p1 [cortex_m]
0001197 I FPU present: FPv4-SP-D16-M [cortex_m]
0001199 I 4 hardware watchpoints [dwt]
0001202 I 6 hardware breakpoints, 4 literal comparators [fpb]
0001208 I RTT control block search range [0x20000000, 0x010000] [rtt_cmd]
0003235 I _SEGGER_RTT @ 0x20006efc with 3 aUp and 3 aDown [rtt_cmd]
root@rtt: 

[flit]

Ah, thanks for the report! Most likely related to #1443 or #1527. I'll try to reproduce.

[flit]

@yannroth Do you have a sample executable that you could attach?

I built the Zephyr threads sample for microbit v2 (with some devicetree hacks) with the console configured to RTT, and pyocd was able to find the control block.

0000202 I Target type is nrf52833 [board]
0000220 I DP IDR = 0x2ba01477 (v1 rev2) [dap]
0000278 I AHB-AP#0 IDR = 0x24770011 (AHB-AP var1 rev2) [discovery]
0000279 I AP#1 IDR = 0x02880000 (AP var0 rev0) [discovery]
0000279 I NRF52833 not in secure state [target_nRF52]
0000281 I AHB-AP#0 Class 0x1 ROM table #0 @ 0xe00ff000 (designer=244 part=00d) [rom_table]
0000282 I [0]<e000e000:SCS v7-M class=14 designer=43b:Arm part=00c> [rom_table]
0000283 I [1]<e0001000:DWT v7-M class=14 designer=43b:Arm part=002> [rom_table]
0000283 I [2]<e0002000:FPB v7-M class=14 designer=43b:Arm part=003> [rom_table]
0000284 I [3]<e0000000:ITM v7-M class=14 designer=43b:Arm part=001> [rom_table]
0000285 I [4]<e0040000:TPIU M4 class=9 designer=43b:Arm part=9a1 devtype=11 archid=0000 devid=ca1:0:0> [rom_table]
0000286 I [5]<e0041000:ETM M4 class=9 designer=43b:Arm part=925 devtype=13 archid=0000 devid=0:0:0> [rom_table]
0000287 I CPU core #0 is Cortex-M4 r0p1 [cortex_m]
0000288 I FPU present: FPv4-SP-D16-M [cortex_m]
0000289 I This appears to be an nRF52833 QIAA A0 [target_nRF52]
0000290 I 4 hardware watchpoints [dwt]
0000291 I 6 hardware breakpoints, 4 literal comparators [fpb]
0000317 I 3 up channels and 3 down channels found [rtt_cmd]
0000317 I Reading from up channel 0 ("Terminal") [rtt_cmd]
0000318 I Writing to down channel 0 ("Terminal") [rtt_cmd]
*** Booting Zephyr OS build zephyr-v3.3.0-3914-gb0668cc586d9 ***
Toggled led0; counter=0
Toggled led1; counter=0
…

[yannroth]

I was trying to generate a binary but I couldn't reproduce the issue today. I guess it's an Heisenbug... I'll open a new issue If I encounter it again and manage to generate a binary that reproduce it.

[tdasika]

I'm facing similar issue with STM32F746G-DISCO board, 'control block is not found' with pyocd 0.35.1 when searched in a valid range and works fine with older version of pyocd, 0.34.3
Can someone help me here.?
Thanks in Advance.!

0002736 I Target type is stm32f746nghx [board]
0002818 I DP IDR = 0x5ba02477 (v2 rev5) [dap]
0002856 I debugvar 'DbgMCU_APB1_Fz' = 0x0 (0) [pack_target]
0002861 I debugvar 'DbgMCU_APB2_Fz' = 0x0 (0) [pack_target]
0002861 I debugvar 'DbgMCU_CR' = 0x7 (7) [pack_target]
0002866 I debugvar 'TraceClk_Pin' = 0x40002 (262146) [pack_target]
0002872 I debugvar 'TraceD0_Pin' = 0x40003 (262147) [pack_target]
0002872 I debugvar 'TraceD1_Pin' = 0x40004 (262148) [pack_target]
0002872 I debugvar 'TraceD2_Pin' = 0x40005 (262149) [pack_target]
0002872 I debugvar 'TraceD3_Pin' = 0x40006 (262150) [pack_target]
0002879 I AHB-AP#0 IDR = 0x74770001 (AHB-AP var0 rev7) [discovery]
0002881 I AHB-AP#0 Class 0x1 ROM table #0 @ 0xe00fd000 (designer=020:ST part=449) [rom_table]
0002883 I [0]<e00fe000:ROM class=1 designer=43b:Arm part=4c8> [rom_table]
0002883 I   AHB-AP#0 Class 0x1 ROM table #1 @ 0xe00fe000 (designer=43b:Arm part=4c8) [rom_table]
0002886 I   [0]<e00ff000:ROM class=1 designer=43b:Arm part=4c7> [rom_table]
0002886 I     AHB-AP#0 Class 0x1 ROM table #2 @ 0xe00ff000 (designer=43b:Arm part=4c7) [rom_table]
0002888 I     [0]<e000e000:SCS v7-M class=14 designer=43b:Arm part=00c> [rom_table]
0002889 I     [1]<e0001000:DWT v7-M class=14 designer=43b:Arm part=002> [rom_table]
0002890 I     [2]<e0002000:FPB v7-M class=14 designer=43b:Arm part=00e> [rom_table]
0002891 I     [3]<e0000000:ITM v7-M class=14 designer=43b:Arm part=001> [rom_table]
0002893 I   [1]<e0041000:ETM M7 class=9 designer=43b:Arm part=975 devtype=13 archid=4a13 devid=0:0:0> [rom_table]
0002895 I [1]<e0040000:TPIU M7 class=9 designer=43b:Arm part=9a9 devtype=11 archid=0000 devid=ca1:0:0> [rom_table]
0002898 I CPU core #0 is Cortex-M7 r0p1 [cortex_m]
0002899 I FPU present: FPv5-SP-D16-M [cortex_m]
0002900 I Setting core #0 (Cortex-M7) default reset sequence to ResetSystem [pack_target]
0002901 I 4 hardware watchpoints [dwt]
0002903 I 8 hardware breakpoints, 1 literal comparators [fpb]
0015606 C Control block not found [__main__]

[flit]

@tdasika Can you make the code you're using available? Or just the ELF and linker map file might be sufficient. It'll be hard to debug without being able to reproduce it. I don't have a Disco-F746, but I can at least take a look at the memory image.

[tdasika]

I debugged it further and found that pyocd is always searching for control_block_id with 16 bytes string (when the block id is less than 16 bytes, it is padding with ‘\0’)
So, when ‘SEGGER RTT’ is the block id to be found, it is searching for 4 words (16 bytes) with zero padding instead of 10 bytes(’SEGGER RTT’) where some junk characters may be present and resulting in failure ‘Control block not found'
I have fixed it locally and now rtt is setup

[flit]

@tdasika Awww, that's no good… thanks for debugging it! Since you have a fix, could you please create a pull request? Also, note #1580.

[cy18]

I runs into exactly the same problem. Version 0.34.3 works as expected, while 0.35.1 fails.

[tdasika]

Rasied a PR to only search for the length of the control block ID provided during the rtt setup,
#1583