Implementación de JTAG en dispositivos Arm Core

Este artículo le enseñará sobre la intersección entre los dispositivos JTAG y Arm core, con especial atención a la interfaz Arm Debug o ADI.

Hasta ahora, en nuestra serie sobre JTAG, hemos analizado el estándar IEEE 1149.1, incluido el controlador del puerto de acceso de prueba (TAP) y la máquina de estado TAP. Luego, revisamos las diferentes interfaces físicas disponibles para trabajar con JTAG, incluidos los pines comunes para conectores y las interfaces JTAG y sondas de depuración disponibles en el mercado.

En este artículo, vamos a apartarnos ligeramente del estándar JTAG y, en su lugar, veremos cómo se implementa JTAG en los dispositivos centrales ARM ubicuos.

¿Qué es Arm?

Arm se refiere a una arquitectura de procesador, junto con una gran cantidad de propiedad intelectual relacionada con las interfaces de microprocesador y microcontrolador. Cuando las PC de consumo tienden a utilizar procesadores derivados de x86, PowerPC o MIPS, la electrónica integrada se implementa con mayor frecuencia con procesadores Arm-core.

El “núcleo” de los procesadores se distribuye a fabricantes como ST Microelectronics o NXP, y estos fabricantes luego agregan características periféricas adicionales, como interfaces I2C y SPI, ADC y DAC, interfaces USB, etc.

Las arquitecturas Arm están versionadas como ARMv, por ejemplo ARMv2 (que data de 1987), ARMv6 (procesadores producidos en 2002-2005) y así sucesivamente, y los núcleos de procesador que utilizan esas arquitecturas están marcados como serie ARMx (ARM1, ARM6, ARM7), y más recientemente, como la serie ARM Cortex-A / R / M para aplicaciones de alto rendimiento (Cortex-A), tiempo real (Cortex-R) y microcontroladores (Cortex-M). El control de versiones de la arquitectura sigue la denominación del sufijo Cortex, convirtiéndose en versiones como ARMv6-M, ARMv7-R, ARMv7-A.

La interfaz de depuración de Arm tiene el nombre de Arm CoreSight Architecture; esto incluye la interfaz de depuración (Arm Debug Interface, ADI), las macrocélulas de seguimiento integradas (ETM), los puertos de seguimiento en serie de alta velocidad (HSSTP) y la arquitectura de seguimiento del flujo del programa CoreSight. El ADI forma la base para las operaciones de depuración con procesadores Arm-core, y parte de este estándar incluye una interfaz JTAG así como la alternativa Serial Wire Debug (SWD). El tema de este artículo es la ADI y, en particular, las capas de interfaz de hardware.

Introducción a la interfaz Arm Debug (ADI)

Arm Debug Interface (ADI) es una especificación tanto de la interfaz de hardware como de la interfaz lógica para la depuración entre un host y uno o más dispositivos. Actualmente, la mayoría de los procesadores están implementando ADIv5 (especificado en Arm IHI0031E), mientras que el ADIv6 más nuevo (ver Arm IHI0074C) se está introduciendo gradualmente. Debido a que es más popular, nos centraremos aquí en el estándar ADIv5.

La ADI define un puerto de acceso de depuración (DAP), compuesto por un puerto de depuración (DP) y puertos de acceso (AP). El DAP es la "unidad" principal de la interfaz de depuración. Un dispositivo determinado tendrá un puerto de depuración, que maneja la conexión física con un depurador, así como varios puertos de acceso que brindan acceso a los recursos del sistema, como registros de depuración, registros de puertos de rastreo, una tabla ROM o memoria del sistema. Por lo tanto, el DP incluye la conexión física (JTAG, SWD), así como algunos registros integrados, y cada AP tiene sus conexiones al sistema y una serie de sus propios registros.

En ADIv5, hay dos tipos de puertos de depuración y (en términos generales) tres tipos de puertos de acceso. Los DP pueden ser JTAG-DP o SWD-DP, denominados así por la interfaz utilizada para conectarse al DAP desde fuera del dispositivo. Los AP pueden ser MEM-AP, que brindan acceso a los recursos mediante el direccionamiento (análogo al mapeo de memoria, de ahí el nombre), JTAG-AP, lo que permite que las cadenas de escaneo JTAG se conecten a toda la unidad de depuración (el DAP) y específicos del proveedor AP, que no están especificados por Arm. Los MEM-AP son, con mucho, los más comunes y útiles, por lo que no cubriremos los otros tipos aquí.

En el contexto de JTAG, esperaríamos que la interfaz de depuración proporcione códigos de instrucción JTAG, así como funciones JTAG específicas del proveedor. De hecho, el estándar ADIv5 proporciona las siguientes instrucciones:

• EXTEST (0b00000000)
• MUESTRA (0b00000001)
• PRECARGA (0b00000010)
• INTEST (0b00000100)
• ABRAZADERA (0b00000101)
• HIGHZ (0b00000110)
• ABORTAR (0b11111000)
• DPACC (0b11111010)
• APACC (0b11111011)
• IDCODE (0b11111110)
• BYPASS (0b11111111)

Además, los registros de datos de JTAG incluyen:

• ABORTAR (35 bits), registrarse para forzar la cancelación de un puerto de acceso
• DPACC (35 bits), registro de acceso de lectura / escritura del puerto de depuración
• APACC (35 bits), registro de acceso de lectura / escritura del puerto de acceso
• IDCODE (32 bits)
• BYPASS (1 bit)

Lo que debe destacarse aquí son las instrucciones DPACC y APACC, y los registros de datos asociados. DPACC (Debug Port Access) y APACC (Access Port Access) son las instrucciones / registros que se utilizan para pasar comandos a los DP y AP asociados de un dispositivo. Al establecer diferentes valores en los registros de datos DPACC o APACC, el depurador puede ejecutar diferentes operaciones, generalmente interactuando con los registros de los propios DP y AP. Tenga en cuenta la diferencia entre estos registros DPACC y APACC (registros JTAG) y los registros integrados en los DP y AP.

La metodología general aquí es que el depurador usa la interfaz JTAG o SWD para ejecutar instrucciones pasando por la máquina de estado TAP, luego las instrucciones toman los datos y los cargan en el DP o AP, y dependiendo de los datos, diferentes registros dentro se accede al DP o AP, proporcionando el enlace deseado al sistema.

Entonces, ¿qué son los registros DP y AP? Los registros DP disponibles incluyen:

• CTRL / STAT, utilizado para controlar y obtener información de estado sobre el DP
• DLCR, registro de control de enlace de datos, controla el modo de funcionamiento del enlace de datos
• DLPIDR, registro de identificación del protocolo de enlace de datos, información de la versión del protocolo
• DPIDR, registro de identificación del puerto de depuración, información del puerto de depuración
• EVENTSTAT, registro de estado de eventos, utilizado por el sistema para señalar un evento al depurador externo
• RDBUFF, registro de búfer de lectura, proporciona una operación de lectura; depende de DP (JTAG o SWD)
• SELECT, AP Seleccionar registro, selecciona un puerto de acceso y los bancos de registros activos con ese AP; selecciona el banco de direcciones DP
• TARGETID, proporciona información sobre el objetivo cuando el host está conectado a un solo dispositivo

Mientras que los registros MEM-AP son:

• Registro de palabra de control / estado (CSW, 0x00), contiene información de control y estado
• Transferir el registro de direcciones (TAR, 0x04), contiene la dirección para el próximo acceso al sistema de memoria o al recurso del sistema
• Registro de lectura / escritura de datos (DRW, 0x0C), establece la lectura o escritura de la dirección en TAR; si lee DRW, el acceso se establece en lectura; si escribe en DRW, el acceso está configurado para escribir
• Los registros de datos bancarios (BD0 a BD3, 0x10, 0x14, 0x18, 0x1C) brindan acceso directo de lectura o escritura a cuatro bloques de memoria de 32 bits, comenzando en la dirección en TAR
• Registro de configuración (CFG, 0xF4), información sobre la configuración de MEM-AP
• Registro de dirección base de base (BASE, 0xF8), puntero al sistema de memoria, ya sea el inicio de un conjunto de registros de depuración o el inicio de una tabla ROM
• Registro de identificación (IDR, 0xFC), identifica el MEM-AP.

Las conexiones se muestran esquemáticamente en la Figura 1, a continuación.

Figura 1. Arme el diagrama de la interfaz de depuración, que resume las conexiones. Nota:no se muestran todos los registros para DP y AP.

Los detalles de los registros DP / AP y la asignación de memoria se pueden encontrar en la especificación, IHI 0031E. En lugar de profundizar en los detalles, me gustaría centrarme en el otro tipo de puerto de depuración, el SWD-DP, y cómo implementa JTAG usando solo dos cables.

Depuración de cables en serie (SWD)

Si bien el JTAG-DP es un ejemplo común y familiar de una interfaz de depuración, lo más relevante para nuestra discusión es la alternativa JTAG definida para dispositivos Arm, Arm Serial Wire Debug (SWD). SWD se desarrolló como una interfaz de dos cables para dispositivos Arm-core con un número limitado de pines. Como los microcontroladores tienden a ser bastante densos en periféricos, la mayoría de los dispositivos Cortex-M implementarán SWD en lugar de JTAG completo para ahorrar espacio en los pines. Entonces, ¿cómo funciona este protocolo?

SWD se especifica en la especificación ADIv5 (capítulo B4). Los pines TDI y TDO de JTAG se reemplazan por un solo pin bidireccional llamado SWDIO; el pin de selección de modo de prueba (TMS) se elimina por completo; y el reloj (TCK) sigue siendo el mismo (reetiquetado CLK o SWCLK). Por lo tanto, SWD usa solo dos pines en comparación con los cuatro pines utilizados en JTAG. Para que esto funcione, SWD se basa en la naturaleza repetitiva de las operaciones JTAG:la máquina de estado se manipula, los datos se mueven hacia adentro o hacia afuera y el proceso se repite. La diferencia con SWD es que no existe una máquina de estado. En cambio, los comandos se emiten en serie a través de SWDIO, y luego ese mismo pin se usa para leer o escribir datos.

Hay tres fases en la comunicación SWD:solicitud de paquetes, reconocimiento y transferencia de datos. Durante la solicitud de paquete, la plataforma de host emite una solicitud al DP, y esto debe ir seguido de una respuesta de reconocimiento. Si la solicitud de paquete fue una solicitud de lectura o escritura de datos, y hubo un acuse de recibo válido, el sistema ingresa a la fase de transferencia de datos, donde los datos se registran (escritura) o se registran (lectura) a través de SWDIO. Después de una transferencia de datos, el host es responsable de iniciar una solicitud de paquete o de manejar la interfaz SWD con ciclos inactivos (marcando SWDIO LOW). Se aplica una verificación de paridad a las solicitudes de paquetes y las fases de transferencia de datos.

Los detalles de SWD se comprenden mejor al ver un diagrama de tiempo, que se muestra en la Figura 2.

Figura 2. Diagramas de tiempo que muestran operaciones de lectura y escritura para depuración de cables en serie. [Haga clic para ampliar]

Las operaciones de lectura y escritura comienzan de la misma manera, comenzando con el host que conduce la línea SWDIO a un bit de inicio, que es una señal ALTA. A esto le sigue la configuración, que incluye el bit de acceso AP o DP (APnDP), el bit de lectura o escritura (RnW), la dirección (A [2:3]), un bit de paridad (PAR) y un bit de parada ( una señal BAJA), seguida finalmente por un bit de estacionamiento, que es cuando el host impulsa la línea ALTA antes de que la línea entre en cambio. Durante el cambio, ni el objetivo ni el anfitrión pueden conducir la línea.

Dependiendo del valor de RnW, se selecciona una operación de lectura o escritura. Si escribe, el destino proporciona una señal ACK de 3 bits, luego hay otro período de respuesta, seguido de los datos de 32 bits que se escribirán (WDATA) y un bit de paridad. Si está leyendo, el objetivo proporciona un ACK y luego continúa impulsando la línea con los datos de lectura de 32 bits (RDATA), seguidos de un bit de paridad. Si ha ocurrido un error, los bits ACK indicarán la falla y el host puede intentar reiniciar la operación. Observe que WDATA y RDATA se transmiten primero con el bit menos significativo (LSb), indicado en la Figura 2 escribiendo WDATA [0:31] en lugar de WDATA [31:0].

El documento Arm IHI0031E proporciona más diagramas de tiempo para aclarar varios casos en la comunicación, pero los anteriores son los casos de uso principales. Vale la pena señalar que hay (al momento de escribir este artículo) dos versiones de SWD; SWDv1 admite solo una conexión entre un host y un destino (punto a punto), mientras que SWDv2 implementa la comunicación de un solo host y múltiples destinos (multipunto). La versión 2 es casi compatible con la versión 1, salvo algunos casos extremos.

Otras variantes de JTAG

SWD no es la única variante de dos cables del estándar JTAG IEEE 1149.1. En particular, el estándar IEEE 1149.7 proporciona una interfaz JTAG de recuento reducido de pines (2 cables). Otros estándares 1149.x como IEEE 1149.4 (Estándar para bus de prueba de señal mixta) e IEEE 1149.6 (Estándar de escaneo de límites de redes digitales avanzadas) se han desarrollado en las últimas dos décadas y brindan funcionalidad adicional para aplicaciones más involucradas. Esto incluye cosas como pruebas de escaneo de límites analógicos y capacidades mejoradas para líneas diferenciales y acopladas a CA.

Los estándares más actualizados están disponibles en el sitio web de la Asociación de Estándares IEEE.

Conclusión

Con esto concluye nuestra cobertura de JTAG y SWD. A lo largo de esta serie, hemos aprendido de dónde proviene JTAG, cómo funciona y cómo se usa para depurar y programar dispositivos. Hemos analizado las conexiones físicas para JTAG, incluidos los conectores y las interfaces disponibles, tanto comerciales como de código abierto. Finalmente, concluimos con una descripción general de la implementación de JTAG para las populares tecnologías centrales del procesador Arm, incluida la interfaz SWD de dos cables.

Desde aquí, podemos salir y usar con confianza las funciones de depuración y programación de nuestros dispositivos integrados, aprendiendo los detalles para diferentes implementaciones y haciendo el mejor uso de nuestro tiempo.