SWD AHB-AP access gives ACK_FAULT

Question

When attempting to debug a STM32L471RGT6 chip over SWD, I encounter an ACK_FAULT whenever sending an AP request to halt the core.

I've implemented the following sequences which all work correctly, getting an ACK_OK for every relevant DP/AP request:

• Select SW-DP on the SWJ-DP interface
• Assert the IDCODE value on the debug port
• Set the CxxxPWRUPREQ bits on the CTRL/STATUS register and assert the respective ACKs
• Assert the IDR register value on the AHB-AP

The next step is to halt the core, enable halt-on-reset, and reset the core to get it into a known state to reprogram the flash memory. When I send the halt command by writing 0xA05F0003 (DBGKEY | C_HALT | C_DEBUGEN) to 0xE000EDF0 (DHCSR register in AHB-AP), I get an ACK_OK.

But then, when attempting to read that same register to check the S_HALT bit, instead of an ACK_WAIT or ACK_OK like I was expecting, I get an ACK_FAULT (0b001 LSB). I retried the entire initialization sequence, but instead, reading the CTRL/STATUS register on the debug port immediately after the AP request to halt the core, and the STICKYERR flag is indeed set.

Does anyone know why this AP request is faulting and how to resolve it?

Answer 1

The issue I found out was when I wrote to the CSW register to configure the access field-size in AHB-AP, I inadvertently cleared the MasterType[29], Hprot1[25], Res1[24] and DbgStatus[6] bits documented in the Cortex-M series cores.

My mistake was using only the ARM Debug Interface Specification as reference for the CSW register, which does not contain documentation on these AHB-AP implementation-specific bits for the Cortex-M series cores.

In the ARM Debug Interface Specification, it documents the DeviceEn[6] bit as read-only rather than implementation-specific read/write access, and does not elaborate on the implementation-specific bits reserved in [30:24].

I confirmed that this was the problem when I used an oscilloscope to inspect the data phase of the first CSW write request from a SEGGER programmer connected to the same board and found that it wrote 0x23000052, which is

MasterType[29] = 0b1
Hprot1[25]     = 0b1
Reserved[24]   = 0b1
DbgStatus[6]   = 0b1
AddrInc[5:4]   = 0b01
Size[2:0]      = 0b010