Nordic Trace Buffer CID from the nRF51 series not in database

[aguaviva]

I get an unknown PIDR

>./blackmagic 
Black Magic Debug App v1.9.0-182-g308aec76
 for Black Magic Probe, ST-Link v2 and v3, CMSIS-DAP, JLink and libftdi/MPSSE
Using 0483:3748 4 STMicroelectronics
 STM32 STLink
Listening on TCP port: 2000
Divisor for 4.0000 MHz is 0
 1 0xf0002000: Debug component - Unknown (PIDR = 0x00000004000bb9a3 DEVTYPE = 0x13 ARCHID = 0x0000)

On the GDB side:

> arm-none-eabi-gdb microbit-samples
GNU gdb (GNU Arm Embedded Toolchain 10.3-2021.10) 10.2.90.20210621-git
[omitted some copyright messages]
Reading symbols from microbit-samples...
(gdb) target extended-remote localhost:2000
Remote debugging using localhost:2000
(gdb) monitor swdp_scan
Target voltage: 3.05V
Available Targets:
No. Att Driver
 1      Nordic nRF51 M0
(gdb) 

[dragonmux]

That's an intriguing unknown CIDR (CoreSight Component ID Register value) for the component at 0xf0002000 - though, we will note it appears not to be preventing debug from working properly.

We'll give the datasheet/reference manual a look and see if they document what is at that address. We'll update this issue with our findings and let you know if we end up adding a new entry to the component lookup table in adiv5.c

The code generating that particular message is this:

blackmagic/src/target/adiv5.c

Lines 628 to 634 in 308aec7

	if (arm_component_lut[i].arch == aa_end) {
	DEBUG_WARN("%s%" PRIu32 " 0x%" PRIx32 ": %s - Unknown (PIDR = 0x%08" PRIx32 "%08" PRIx32 " DEVTYPE = "
	"0x%02x ARCHID = "
	"0x%04x)\n",
	indent, num_entry, addr, cidc_debug_strings[cid_class], (uint32_t)(pidr >> 32U), (uint32_t)pidr,
	dev_type, arch_id);
	}

[aguaviva]

I did try adding that entry to the device database. The error didn't show up but subsequent GDB commands timed out. Prob I did something wrong. I'll try again later today with other settings.

…

On Wed, Feb 22, 2023, 02:43 Rachel Mant ***@***.***> wrote: That's an intriguing unknown CIDR (CoreSight Component ID Register value) for the component at 0xf0002000 - though, we will note it appears not to be preventing debug from working properly. We'll give the datasheet/reference manual a look and see if they document what is at that address. We'll update this issue with our findings and let you know if we end up adding a new entry to the component lookup table in adiv5.c The code generating that particular message is this: https://github.com/blackmagic-debug/blackmagic/blob/308aec7627d0bcad16fad0825ee052ac17e5f149/src/target/adiv5.c#L628-L634 — Reply to this email directly, view it on GitHub <#1394 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABHVYE74WPTNZTCB2UY7IW3WYVVMDANCNFSM6AAAAAAVDWR6AI> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[dragonmux]

Unfortunately that particular bit of code is putting the PIDR out to the debug port, not the CIDR value that triggered the error - they are two different values. That said, just enough information in present we can probably RE what the CIDR read was.

As a note, any new entries in arm_component_lut must go before the final entry which is a special sentinel to halt iteration.

[dragonmux]

Aha! This forum thread on the Nordic website indicates this is the "Nordic Trace Buffer" (MTB-like thing) which is not recommended to be used. We can add an entry to the component table for it with that in hand

[aguaviva]

You are awesome, let me know how I can help, as you see I am not afraid of the debugger ;)

[dragonmux]

Sorry that it's taken 2 weeks to get to but you should now be able to use the attached branch to see a complete and working enumeration for the nRF processors, no more unknown component

[aguaviva]

Many thanks! Your fix was similar to what I attempted, but there might be something else failing, (hopefully this issue helps uncover something interesting!)

Now all goes well until I issue the command 'run'

see below:

.gdbinit

target extended-remote :2000
monitor swdp_scan
attach 1
load microbit-samples-combined.hex

GDB output:

$ arm-none-eabi-gdb microbit-samples-combined.hex 
GNU gdb (GNU Arm Embedded Toolchain 10.3-2021.10) 10.2.90.20210621-git
[ copyright stuff]
Reading symbols from microbit-samples-combined.hex...
(No debugging symbols found in microbit-samples-combined.hex)
Target voltage: 3.06V
Available Targets:
No. Att Driver
 1      Nordic nRF51 M0
0x0000d16c in ?? ()
Loading section .sec1, size 0x7c0 lma 0x0
Loading section .sec2, size 0xf000 lma 0x1000
Loading section .sec3, size 0x6918 lma 0x10000
Loading section .sec4, size 0x6438 lma 0x18000
Loading section .sec5, size 0x3874 lma 0x3c000
Loading section .sec6, size 0x20 lma 0x3fc00
Loading section .sec7, size 0x4 lma 0x10001014
Start address 0x0003c0c0, load size 130472
Transfer rate: 26 KB/sec, 952 bytes/write.
(gdb) r
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: microbit-samples-combined.hex 

then it gets stuck at the last line

On the blackmagic side, in the log, this is what black magic reports when the hang happens

mdline: ><
ap_memread @ e000edf0 len 4: 03 00 03 00
ap_memread @ e000edf0 len 4: 03 00 03 00
ap_mem_write_sized @ e000ed0c len 4, align 4: 04 00 fa 05
ap_memread @ e000edf0 len 4: 03 00 03 03
ap_memread @ e000edf0 len 4: 03 00 03 00
ap_mem_write_sized @ e000ed30 len 4, align 4: 1f 00 00 00
Read CTRL/STAT: 0xf0000040
Write DP_ABORT: 0x00000000
DP Error 0x00000000
*** Unsupported packet: qAttached
*** Unsupported packet: vCont?
ap_mem_write_sized @ e000edf0 len 4, align 4: 01 00 5f a0
ap_memread @ e000edf0 len 4: 01 00 00 01
ap_memread @ e000edf0 len 4: 01 00 00 01
ap_memread @ e000edf0 len 4: 01 00 00 01
ap_memread @ e000edf0 len 4: 01 00 00 01
ap_memread @ e000edf0 len 4: 01 00 00 01
ap_memread @ e000edf0 len 4: 01 00 00 01
ap_memread @ e000edf0 len 4: 01 00 00 01
ap_memread @ e000edf0 len 4: 01 00 00 01
ap_memread @ e000edf0 len 4: 01 00 00 01
ap_memread @ e000edf0 len 4: 01 00 00 01
ap_memread @ e000edf0 len 4: 01 00 00 01
ap_memread @ e000edf0 len 4: 01 00 00 01
ap_memread @ e000edf0 len 4: 01 00 00 01
ap_memread @ e000edf0 len 4: 01 00 00 01
ap_memread @ e000edf0 len 4: 01 00 00 01
ap_memread @ e000edf0 len 4: 01 00 00 01
ap_memread @ e000edf0 len 4: 01 00 00 01
ap_memread @ e000edf0 len 4: 01 00 00 01
ap_memread @ e000edf0 len 4: 01 00 00 01
ap_memread @ e000edf0 len 4: 01 00 00 01
ap_memread @ e000edf0 len 4: 01 00 00 01
ap_memread @ e000edf0 len 4: 01 00 00 01
ap_memread @ e000edf0 len 4: 01 00 00 01
ap_memread @ e000edf0 len 4: 01 00 00 01
ap_memread @ e000edf0 len 4: 01 00 00 01
ap_memread @ e000edf0 len 4: 01 00 00 01
ap_memread @ e000edf0 len 4: 01 00 00 01
ap_memread @ e000edf0 len 4: 01 00 00 01
ap_memread @ e000edf0 len 4: 01 00 00 01
ap_memread @ e000edf0 len 4: 01 00 00 01
ap_memread @ e000edf0 len 4: 01 00 00 01
ap_memread @ e000edf0 len 4: 01 00 00 01
ap_memread @ e000edf0 len 4: 01 00 00 01
ap_memread @ e000edf0 len 4: 01 00 00 01
ap_memread @ e000edf0 len 4: 01 00 00 01
ap_memread @ e000edf0 len 4: 01 00 00 01
ap_memread @ e000edf0 len 4: 01 00 00 01
ap_memread @ e000edf0 len 4: 01 00 00 01
ap_memread @ e000edf0 len 4: 01 00 00 01
ap_memread @ e000edf0 len 4: 01 00 00 01
ap_memread @ e000edf0 len 4: 01 00 00 01
ap_memread @ e000edf0 len 4: 01 00 00 01
ap_memread @ e000edf0 len 4: 01 00 00 01
ap_memread @ e000edf0 len 4: 01 00 00 01
ap_memread @ e000edf0 len 4: 01 00 00 01
ap_memread @ e000edf0 len 4: 01 00 00 01
ap_memread @ e000edf0 len 4: 01 00 00 01
ap_memread @ e000edf0 len 4: 01 00 00 01
ap_memread @ e000edf0 len 4: 01 00 00 01
ap_memread @ e000edf0 len 4: 01 00 00 01
ap_memread @ e000edf0 len 4: 01 00 00 01
ap_memread @ e000edf0 len 4: 01 00 00 01
ap_memread @ e000edf0 len 4: 01 00 00 01
ap_memread @ e000edf0 len 4: 01 00 04 01
ap_memread @ e000edf0 len 4: 01 00 04 01
ap_memread @ e000edf0 len 4: 01 00 04 01
ap_memread @ e000edf0 len 4: 01 00 04 01
ap_memread @ e000edf0 len 4: 01 00 04 01
ap_memread @ e000edf0 len 4: 01 00 04 01
ap_memread @ e000edf0 len 4: 01 00 04 01
ap_memread @ e000edf0 len 4: 01 00 04 00
ap_memread @ e000edf0 len 4: 01 00 04 00
ap_memread @ e000edf0 len 4: 01 00 04 00
ap_memread @ e000edf0 len 4: 01 00 04 00
ap_memread @ e000edf0 len 4: 01 00 04 01
ap_memread @ e000edf0 len 4: 01 00 04 01
ap_memread @ e000edf0 len 4: 01 00 04 01
ap_memread @ e000edf0 len 4: 01 00 04 00
ap_memread @ e000edf0 len 4: 01 00 04 00
ap_memread @ e000edf0 len 4: 01 00 04 00
ap_memread @ e000edf0 len 4: 01 00 04 01
ap_memread @ e000edf0 len 4: 01 00 04 01
ap_memread @ e000edf0 len 4: 01 00 04 00
ap_memread @ e000edf0 len 4: 01 00 04 00
ap_memread @ e000edf0 len 4: 01 00 04 01
ap_memread @ e000edf0 len 4: 01 00 04 00
ap_memread @ e000edf0 len 4: 01 00 04 01
ap_memread @ e000edf0 len 4: 01 00 04 01
....
...
.

it seems it is polling for something that never happens, although that might be influenced by the commands qAttached and vCont fail

Do you have any insights or any idea how I can help debug this?

[dragonmux]

With regards the failing GDB commands, enabling remote protocol debugging in GDB (set debug remote 1) will give you more information on the flows occurring there.

It would be interesting what the output of compare-sections says after load in case this is in part an issue Flashing the part.

In a similar vein, we would be interested in the results of you rebasing the feature branch on top of fix/cortexm-halt-resume-correctness and how that impacts the apparent failure mode you're seeing as that contains a whole pile of improvements to the halt and resume process, a complete rewrite of the remote protocol used here, etc. This also includes improved logging and error reporting