El acceso SWD AHB-AP da ACK_FAULT

Cuando intento depurar un chip STM32L471RGT6 a través de SWD, encuentro un ACK_FAULT cada vez que envío una solicitud de AP para detener el núcleo.

Implementé las siguientes secuencias que funcionan correctamente, obteniendo un ACK_OK para cada solicitud de DP/AP relevante:

  • Seleccione SW-DP en la interfaz SWJ-DP
  • Afirme el valor IDCODE en el puerto de depuración
  • Establezca los bits CxxxPWRUPREQ en el registro CTRL/STATUS y confirme los ACK respectivos
  • Afirmar el valor del registro IDR en el AHB-AP

El siguiente paso es detener el núcleo, habilitar la detención al reiniciar y reiniciar el núcleo para ponerlo en un estado conocido para reprogramar la memoria flash. Cuando envío el comando detener escribiendo 0xA05F0003 (DBGKEY | C_HALT | C_DEBUGEN) a 0xE000EDF0 (registro DHCSR en AHB-AP), obtengo un ACK_OK.

Pero luego, cuando intento leer ese mismo registro para verificar el bit S_HALT, en lugar de un ACK_WAIT o ACK_OK como esperaba, obtengo un ACK_FAULT (0b001 LSB). Volví a intentar toda la secuencia de inicialización, pero en su lugar, leí el registro CTRL/STATUS en el puerto de depuración inmediatamente después de la solicitud de AP para detener el núcleo, y el indicador STICKYERR está realmente configurado.

¿Alguien sabe por qué falla esta solicitud de AP y cómo resolverla?

Respuestas (1)

El problema que descubrí fue cuando escribí en el registro CSW para configurar el tamaño del campo de acceso en AHB-AP, sin darme cuenta borré los bits MasterType[29], Hprot1[25], Res1[24] y DbgStatus[6] documentados en los núcleos de la serie Cortex-M .

Mi error fue usar solo la especificación de interfaz de depuración ARM como referencia para el registro CSW, que no contiene documentación sobre estos bits específicos de implementación de AHB-AP para los núcleos de la serie Cortex-M.

En la Especificación de interfaz de depuración de ARM, documenta el bit DeviceEn[6] como acceso de lectura/escritura de solo lectura en lugar de específico de la implementación, y no explica los bits específicos de la implementación reservados en [30:24].

Confirmé que este era el problema cuando usé un osciloscopio para inspeccionar la fase de datos de la primera solicitud de escritura CSW de un programador SEGGER conectado a la misma placa y descubrí que escribió 0x23000052, que es

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