What's on That Access Port?

Debugging the nRF54LM20’s RISC-V FLPR coprocessor requires selecting the right core, rather than assuming a connection to the Cortex-M33 application core. Zephyr’s Sysbuild organizes firmware for the two cores into separate domains, so `west debug --domain hpf_gpio` targets the FLPR image while the default domain targets the application core. Board configuration passes a J-Link device name to the debugger: `nRF54LM20A_RV32` for the FLPR and `nRF54LM20A_M33` for the Cortex-M33. J-Link’s output shows that it connects differently for each: it selects the FLPR’s access port directly, but searches the available ports for the Cortex-M33.

The explanation then examines the Debug Access Port (DAP), which contains a Debug Port and multiple Access Ports (APs). The nRF54LM20 provides AP 0 for the Cortex-M33, AP 1 for auxiliary access including the FLPR, and AP 2 as Nordic’s control port. The Arm Debug Interface allows a debugger to discover APs by selecting one through the DP’s SELECT register and reading its identification register (IDR) at offset `0xFC`. J-Link’s low-level `WriteDP` and `ReadAP` commands demonstrate this scan: APs 0 and 1 return `0x84770001`, identifying AHB memory access ports, while AP 2 returns `0x32880000`, identifying Nordic’s CTRL-AP. These register-level details show how a debugger can inspect a device’s access paths even when its core-selection behavior is otherwise hidden.