El acceso SWD AHB-AP da ACK_FAULT

Question

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

He implementado las siguientes secuencias que funcionan correctamente, obteniendo un ACK_OK para cada solicitud DP/AP relevante:

• Seleccione SW-DP en la interfaz SWJ-DP
• Confirmar el valor IDCODE en el puerto de depuración
• Establece los bits CxxxPWRUPREQ en el registro CTRL/STATUS y afirma los ACKs respectivos
• Reafirmar el valor del registro IDR en el AHB-AP

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

Pero entonces, al intentar leer ese mismo registro para comprobar 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, la lectura del registro CTRL/STATUS en el puerto de depuración inmediatamente después de la solicitud de AP para detener el núcleo, y la bandera STICKYERR se establece de hecho.

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

Answer 1

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

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

En la Especificación de Interfaz de Depuración ARM, documenta el bit DeviceEn[6] como de sólo lectura en lugar de acceso de lectura/escritura específico de la implementación, y no elabora sobre 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 petición de escritura CSW desde un programador SEGGER conectado a la misma placa y encontré que escribía 0x23000052, que es

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