¿Es JTAG la forma estándar de programar procesadores ARM?

Un ingeniero eléctrico me dijo una vez que cada procesador ARM M3 se puede flashear de la misma manera, sin importar de qué fabricante provenga.

Supongo que quiso decir usar JTAG, ¿o hay otra forma?

Por cierto, tengo la intención de flashear un procesador ARM vacío sin un gestor de arranque.

Los micros basados ​​en ARM se flashean sobre JTAG o SWD. Algunos aceptarán la programación sobre cualquier protocolo, mientras que otros requieren uno u otro. Por ejemplo, Nordic Semiconductor nRF52 es solo SWD. Y el hecho de que todos los M3 se puedan flashear de la misma manera no significa que el software sea libremente intercambiable.

Respuestas (1)

Supongo que quiso decir usar JTAG, ¿o hay otra forma?

Probablemente no lo hizo. ARM tiene su propio estándar de bus de depuración: SWD (depuración de un solo cable), que está muy bien especificado. JTAG, por otro lado, es simplemente un estándar eléctrico y de nivel de registro de desplazamiento, y depende de los fabricantes de dispositivos dar un significado a los puntos finales y las acciones de JTAG.

Los programadores SWD se pueden conseguir por <5€. Busque productos llamados "STLink v2 compatible" más o menos. El ST en el nombre proviene del hecho de que se basan en el protocolo que los adaptadores STmicro USB a SWD hablan entre la computadora host y el adaptador, pero dado que solo "transportan" SWD, funcionan con todos los microcontroladores compatibles con SWD.

En la mayoría de los sistemas de desarrollo, querrá usar OpenOCD como "controlador" para estos dispositivos, de modo que pueda flashear imágenes fácilmente (ya sea directamente a través de OpenOCD o usando, por ejemplo, GDB load). Si está atascado con un sistema operativo absurdo que necesita controladores específicos incluso para dispositivos genéricos, probablemente deba instalar las herramientas de ST.

Por cierto, tengo la intención de flashear un procesador ARM vacío sin un gestor de arranque.

Sí, suena como un caso clásico para SWD: ARM ofrece hardware para eso en sus núcleos, y la mayoría de los fabricantes eligen usar eso y asignar pines.

También tenga en cuenta que la mayoría de los fabricantes (incluido ST) envían sus circuitos integrados "vacíos" con algún tipo de cargador de arranque, sobre el cual puede cargar firmware a través de un puerto serie o incluso USB en el dispositivo, muy útil para la fabricación.

Para un poco de discusión sobre SWD, en realidad recomiendo (por pura diversión que es leer) PoC||GTFO 0x10, pp. 26 , que comienza con una introducción de la infraestructura de depuración de ARM y SWD como protocolo, y luego continúa para explicar cómo usar los ARM conectados a SWD como expansores de E/S sofisticados en lugar de MCU independientes.

Entonces, ¿puede usar SWD para actualizar su programa al procesador? Pensé que era solo para depurar.
Si se programa la producción a través de JTAG o SWD, hay dispositivos que admiten múltiples cargas a la vez para un mayor rendimiento. Ejemplo: elprotronic.com/products?show&id=55 . Además, muchos dispositivos (¿la mayoría? ¿Todos?) admiten la carga de un código de serie a través de USB, UART o lo que elija el fabricante del chip. Esto suele ser solo carga de código y no depuración. Para la mayoría de mis productos, es JTAG/SWD para el desarrollo y luego la actualización en serie en el entorno de producción y, a veces, el distribuidor de chips carga previamente el código (que generalmente es en serie).
La programación de memorias flash MCU sobre SWD en realidad no está estandarizada: los detalles difieren para cada proveedor y, hasta cierto punto, para cada chip. A menudo, lo que termina haciendo es escribir un búfer de datos, escribir un pequeño programa en otra ubicación en la RAM y luego ejecutar ese pequeño programa, que hace las escrituras reales de la memoria flash. O en otras ocasiones, invoca dicho código que está integrado en la ROM de fábrica (que también puede proporcionar la funcionalidad del cargador de arranque). Por lo general, puede lograr las mismas cosas a través de las extensiones JTAG: SWD es básicamente una simplificación de JTAG.
@ChrisStratton Me gustaría estar de acuerdo en que la programación flash no está realmente estandarizada, pero principalmente en el aspecto de que flash no siempre está asignado al mismo espacio de direcciones en AHB. Es una cosa muy "ARM" tener todos los periféricos colgando en el espacio de la memoria, por lo que no conozco ningún proveedor que no conecte su flash al espacio de memoria normal al que puede acceder en el puerto de acceso SWD AHB. Para estar más de acuerdo con usted: sin embargo, a menudo tiene que habilitar las escrituras flash antes de poder borrar/sobrescribir los bancos flash.
Tenga en cuenta que OpenOCD tiene muchos scripts que ya representan diferentes circuitos integrados y especifican dónde está la memoria flash y cómo acceder a ella, por lo que solo tiene que especificar el nombre del archivo de imagen: openocd.org/doc-release/html/…
@MarcusMüller: no es solo la dirección lo que cambia, el procedimiento real para la programación válida es único en el dispositivo; a veces se publica, otras veces es "ni siquiera le diremos cómo, debe invocar nuestra rutina ROM" . No es raro que haya detalles adicionales, por ejemplo, la serie Atmel SAM puede tener bits de fusible que deben configurarse para permitir el arranque desde flash y, opcionalmente, puede intercambiar el direccionamiento de los bancos flash. Sí, openocd encapsula estas cosas, pero el punto es que hay detalles para encapsular, tuve que parchearlo para que sea único dentro de una familia compatible.
¡@ChrisStratton exactamente! Estás absolutamente en lo correcto; el hecho importante aquí es que flash es un periférico específico del proveedor para el núcleo ARM, y debe consultar con su proveedor sobre cómo usarlo.
¡Guau, ese PoC||GTFO es realmente asombroso!
Bueno, prueba un concepto. De lo contrario, tendría que GTFO.
Entonces, para recapitular todo, ¿NO existe un dispositivo universal para flashear ningún procesador ARM? Si tengo un M3 de un fabricante y otro de un fabricante diferente, ¿entonces ambos pueden tener diferentes formas de flashear?
@ user41666 más complicado que eso: puede usar una interfaz SWD para "hablar" con la mitad de los chips, JTAG para la otra mitad, pero ninguna interfaz especifica qué "decir" para programar el flash. Pero lo considero simplemente un detalle: no se podía ejecutar el firmware de un chip sin modificar en el otro.
¿Es JTAG la forma estándar de programar procesadores ARM?
RespuestasAquíPolítica de privacidad1y, 1v