SWD AHB-AP acceso ACK_FAULT

Navega tus respuestas
1

Al intentar depurar un chip STM32L471RGT6 a través de SWD, encuentro 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
  • Confirme el valor de IDCODE en el puerto de depuración
  • Establezca los bits CxxxPWRUPREQ en el registro CTRL / STATUS y haga valer los ACK respectivos
  • Confirme el valor de registro IDR en el AHB-AP

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

Pero luego, cuando intento leer el 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). Reintenté toda la secuencia de inicialización, pero en cambio, leí el registro CTRL / ESTADO en el puerto de depuración inmediatamente después de la solicitud del AP para detener el núcleo, y el indicador STICKYERR está realmente establecido.

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

    
pregunta Patrick Roberts

1 respuesta

3

El problema que descubrí fue cuando escribí en el registro de 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] bits documentados en los núcleos de la serie Cortex-M .

Mi error fue usar solo la 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 la implementación de AHB-AP para los núcleos de la serie Cortex-M.

En la Especificación de la interfaz de depuración de ARM, documenta el bit DeviceEn [6] como de solo lectura en lugar de acceso de lectura / escritura 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 de 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
    
respondido por el Patrick Roberts

Lea otras preguntas en las etiquetas

¿Puedo conectar el sensor de proximidad inductivo a dos PLC diferentes? ¿Cómo determinar la velocidad de transmisión de datos desde un diagrama de ojo?