nRF54L AUX-AP access port description and usage

[Tomas Vanek]

Hi all,

In the PDF version of nRF54L PRELIMINARY DATASHEET v0.8, in chapter

9.1 Debug access port:

in table 65: Access port overview

is listed AUX access port of AHB-AP with AP ID 1.

Figure 160: Debug and trace overview

shows AUX-AP connected to VPR trough AMBIX0 block.

In table 66 in chapter 9.2 Access port protection:

Access port protection overview registers UICR.AUXAPROTECT, TAMPC.PROTECT.­AP[0].­DBGEN
are described as "These registers control the generation of the AHB-AP DBGEN signal,
which controls debug access to the VPR AHB-AP. This is used to provide debug capability for VPR."

But there is no other info where any VPR debugging resides in AUX-AP memory space.
Moreover I didn't find any readable address in AUX-AP.

FLPR/VPR RISC-V coprocessor DM (debug module) registers are exposed @ 0x4004C000 / 0x5004C000 of APP-AP (AP ID 0)  address space as described
in 8.26.1 Registers

What is AUX-AP for? Is possible to use it for RISC-V DM access?

[ketiljo]

The debug diagram in trace and debug chapter in PS is not very accurate,  the AHB-AP (AP0) can also access the VPR registers. The VPR debug registers are memory mapped on APB00, so they can be accessed through either AP0 and AP1. However, the AUX-AP can access only APB00 space on AMBIX0, a shown below:

The main reason to have AP0 and AP1 (AUX-AP) to debug CM33 and VPR simultaneously using the corresponding APs. So the primary usage for AUX-AP is to use with RISC-V DM access as pointed in the question.

[Tomas Vanek]

Thanks for the reply.

Could you please go into details about accessing RISC-V DM over AUX-AP?

I would expect DM registers at RISC-V debug spec conforming addresses of AUX-AP. But there is no access from SWD DAP.

Datasheet, page 751 reads:

UICR.AUXAPROTECT,
TAMPC.PROTECT.AP[0].DBGEN

These registers control the generation of the AHB-AP DBGEN signal,
which controls debug access to the VPR AHB-AP. This is used to
provide debug capability for VPR.

and

UICR and TAMPC are combined to enable or disable the access port protection. The access port is normally
protected, and is opened when the following conditions are met:
1. UICR.APPROTECT must be Unprotected.
2. The corresponding TAMPC.PROTECT register must be written by firmware. See TAMPC signal protector
for details on the procedure.

Does it mean that AUX-AP access cannot be enabled by a debugger only without running some code on nRF54L?

[Tomas Vanek]

I have the blinky app with egpio sdp overlay loaded. The app calls nrf54l_handle_approtect() which enables NRF_TAMPC->PROTECT.AP[0].DBGEN.CTRL

Both UICR.AUXAPPROTECT[0].PROTECT0 and PROTECT1 are 0xffffffff thus unprotected.

I believe that AUX-AP DBGEN signal should be enabled in this device state. However I see no readable memory accessed trough AUX-AP on standard RISC-V DM locations (e.g. 0x44 for .DMSTATUS)

Where is RISC-V DM mapped on AUX-AP?

[ketiljo]

Tomas Vanek said:

I believe that AUX-AP DBGEN signal should be enabled in this device state

Yes, the signal at TAMPC.PROTECT.AP[0].DBGEN.CTRL register must be set as well (in addition to the UICR PROTECT0/1 state)

Tomas Vanek said:

Where is RISC-V DM mapped on AUX-AP?

You can find it here: 

https://docs.nordicsemi.com/bundle/ps_nrf54L15/page/vpr.html#ariaid-title14

[Tomas Vanek]

Sorry, I'm not asking about AP0 (APP CPU AP) address space. Yes, the RISC-V DM is mapped there. I quoted it in my first question

Tomas Vanek said:

FLPR/VPR RISC-V coprocessor DM (debug module) registers are exposed @ 0x4004C000 / 0x5004C000 of APP-AP (AP ID 0)  address space as described
in 8.26.1 Registers

and you replied

ketiljo said:

The main reason to have AP0 and AP1 (AUX-AP) to debug CM33 and VPR simultaneously using the corresponding APs. So the primary usage for AUX-AP is to use with RISC-V DM access as pointed in the question.

My question is how to use AP1 (AUX-AP) for RISC-V debugging? In the AUX-AP address space there is no DMSTATUS neither @ 0x44 nor @ 0x4004c444. And AFAIK no relevant info in the datasheet.

[ketiljo]

As far as VPR is concerned, it is accessed exactly same way in both AP0 and AP1, the RISC-V debugging registers are memory mapped to the address pointed above.

Tomas Vanek said:

In the AUX-AP address space there is no DMSTATUS neither @ 0x44 nor @ 0x4004c444

See the link in the last post, https://docs.nordicsemi.com/bundle/ps_nrf54L15/page/vpr.html#ariaid-title14

[Tomas Vanek]

I rechecked it again. The registers are accessible on AP0 but NOT on AP1.

All ok on AP0:

> # UICR.AUXAPPROTECT[0].PROTECT0 and PROTECT1
> nrf54l.cpu mdw 0x00FFD040
0x00ffd040: ffffffff
> nrf54l.cpu mdw 0x00FFD05c
0x00ffd05c: ffffffff

> # TAMPC.PROTECT.AP[0].DBGEN.CTRL
> nrf54l.cpu mdw 0x500DC700
0x500dc700: 00000011

> # VPR.DEBUGIF.DMSTATUS
> nrf54l.cpu mdw 0x5004C444
0x5004c444: 00430c82

Just SWD FAULT responses on AP1:

> nrf54l.aux mdw 0x5004C444
Failed to read memory at 0x5004c444
> nrf54l.aux mdw 0x4004C444
Failed to read memory at 0x4004c444
> nrf54l.aux mdw 0x444
Failed to read memory at 0x00000444
> nrf54l.aux mdw 0x44
Failed to read memory at 0x00000044

It not of any help for me if you just repeat what I read several times. There must be an issue! But where?

[ketiljo]

The issue is possibly related to access violations. Could you share with us the AHB-AP CSW register configuration for both AP0 and AP1?

[Tomas Vanek]

Both AP0 and AP1 use OpenOCD default csw 0xa2000000

[Tomas Vanek]

And real values read from CSW are

> nrf54l.dap apreg 0 0
0x02800052
> nrf54l.dap apreg 1 0
0x43800042

[Tomas Vanek]

Setting CSW Prot[0] (bit 24) does the trick and DM registers are accessible.

Thanks!

[Tomas Vanek]

Its a pity that DM is not mapped on AUX-AP from address 0. Both 0.13.2 and 1.0 RISC-V debug specifications in chapter 3.15 Debug Module Registers clearly require

Each DM has a base address (which is 0 for the first DM).

Also the different base 0x4004c400 or 0x5004c400 depending on security setting in SPU complicates the debugger setup.