¿SWD con un chip FTDI es una solución de programador universal?

He buscado por todas partes (de hecho, he pasado los últimos meses tratando de encontrar una respuesta). Tal vez no estoy haciendo las preguntas correctas, o estoy mirando la respuesta a la cara, no estoy seguro. He estado demasiado nervioso para preguntar, pero estoy al final de mi juicio, así que aquí va.

Estoy creando un proyecto que, debido a las limitaciones de tamaño, debe ser muy pequeño. Eso significa una pequeña MCU y una pequeña interfaz de programación. También es de código abierto, por lo que me gustaría mantener la interfaz de programación lo más barata y simple posible (también como estudiante, no quiero gastar mucho si no es necesario).

Este artículo que encontré parece indicarme la posibilidad de una solución universal. Esos chips FTDI son mucho más baratos que cualquier otro programador JTAG (legítimo). En términos generales (para la posteridad), ¿podrán interactuar y programar cualquier MCU ARM que incluya una interfaz SWD?

Específicamente (si es relevante), estoy buscando integrar el módulo SiP SiLabs BGM121 en mi proyecto y estoy tratando de descubrir cómo lo programaría. Ni siquiera me importa necesariamente la depuración en este punto, solo trato de encontrar una solución económica. También entre el SiLabs CP2102 y el FTDI FT2232H, ¿cuál es más probable que funcione?

La mayoría de las soluciones de hardware del voltaje apropiado pueden funcionar si tiene el software adecuado detrás, lo que a menudo significa parchear (o esperar a que alguien más parchee) algo como OpenOCD para admitir un objetivo específico. Algunos enfoques de hardware simplemente funcionan más rápido que otros o manejan mejor los voltajes extremos. El FT2232H es bastante costoso en lo que respecta a las soluciones básicas de silicio: puede transferir el código CMSIS-DAP a cualquier MCU ARM cortex de gama baja con USB, por ejemplo, pero será mucho más lento.
Eso es cierto en el FT2232H. En algún momento del camino, desdibujé las líneas entre el FT232h, que es más barato, pero ¿quizás más antiguo? Voy a descargar e instalar Open-OCD y tratar de comenzar a aprender eso, además de ver qué ofrecen los estudios de simplicidad de SiLabs. ¿Tiene alguna sugerencia para una solución de hardware barata? Pido disculpas por mi ignorancia, estoy empezando a aprender a programar brazos, la hoja de datos para el BGM121 era bastante anodino, pero encontré una nota de aplicación que estoy leyendo de ellos. ¡Gracias por su respuesta!
Su edición de la pregunta no tiene mucho sentido en el contexto de este sitio. Posiblemente podría haberlo publicado como respuesta, entonces al menos la pregunta/respuesta original habría tenido sentido. Probablemente lo mejor sea esperar hasta que tenga una nueva pregunta relacionada con el firmware y preguntar algo nuevo entonces.
Sí, realmente no sé cómo funciona este sitio para ser 100% honesto. ¿Pensé que era la clara difusión de información para la posteridad? Respondí mi propia pregunta y edité la pregunta para reflejar eso, y ayudar a cualquiera que estuviera en la misma posición que yo, de una manera clara (en mi humilde opinión). La información está a la vista ahora. No hago todo el asunto de estrujarme las manos, si encuentro información que me falta, solo estoy agradecido por la información, no por el formato. Pero por supuesto, editaré mi publicación, tienes más experiencia aquí que yo.
y ahora tienes el doble de reputación que antes...

Respuestas (2)

La interfaz ARM SWD es 'genérica' en el sentido de que el protocolo de interfaz no se preocupa por el hardware de destino. Entonces, suponiendo que su dispositivo de programación funcione con el voltaje correcto, sí, puede funcionar con cualquier hardware.

Detrás de la interfaz SWD, los registros que controlan la depuración en el SoC se asignan a la memoria. Aunque estos están estandarizados en cierto sentido, para cualquier cadena de herramientas de depuración a menudo se requiere un grado de personalización (en el lado del software). Por ejemplo, una nueva CPU tendrá un nuevo valor de código de identificación y tal vez algunos registros de control de arquitectura adicionales.

Básicamente, tiene la opción de implementar el protocolo SWD en el software de su PC y usar una interfaz de USB a pines, o implementar el protocolo en un microcontrolador y presentar un punto final USB que 'depura'. Hacer esto último es lo que hacen casi todas las placas de desarrollo con una interfaz de depuración integrada, en la línea de SWDAP y el software DAPLink . A menudo, estas placas de desarrollo están configuradas para que pueda dividir las señales SWD y usarlas para depurar su propio hardware de destino en un diseño de producto final.

Si elige no implementar DAPLink, es posible que esté más limitado en las cadenas de herramientas que admiten su interfaz.

En el pasado, era complicado acceder a la documentación del protocolo SWD, y esto parece haber generado cierto grado de confusión cuando se trata de sondas genéricas. Las antiguas interfaces JTAG anteriores a CoreSight también eran mucho más específicas para dispositivos, con un controlador TAP implementado dentro de la CPU.

Gracias por la respuesta. Definitivamente útil, creo que el camino a seguir podría ser obtener una placa de desarrollo stm32 con el st-link incorporado que luego se puede actualizar con el firmware segger para actualizarlo a un J-link. Creo que lo consideran el j-link lite. Obviamente, se aplican las mismas restricciones de licencia, pero puedo usarlo para mojarme los pies y si termino tratando de vender un proyecto, lo resolveré desde allí. Para unirlo, esta puede ser la mejor opción para un programador/depurador universal económico. Por favor, corríjame si estoy equivocado.
¿Se refiere a las restricciones en el hardware que se está depurando o a las restricciones de la cadena de herramientas? El mbed cmsis-dap no está gravado (hasta donde yo sé) y se puede actualizar en muchas placas de desarrollo (probablemente más barato que comprar dip-dap, que es una pieza independiente de NXP diseñada para la creación de prototipos). No estoy al tanto de ninguna funcionalidad adicional presente en el firmware de otros proveedores (pero nunca necesité mirar).
Lo siento, me refería a las restricciones impuestas por segger para su firmware jlink edu. Lo que dices es interesante. Entonces, si compro una placa de desarrollo stm32, ¿puedo flashear cmsis-dap en la parte st-link de la placa? ¿O es cmsis-dap solo una capa de software? Puedo terminar haciendo eso en cualquier caso. ¡Gracias!

Muy bien, después de investigar más, creo que he encontrado una solución relativamente barata, una placa de desarrollo stm32 se puede actualizar con el firmware DAPLINK, pero no creo que el firmware oficial de github funcione de forma nativa. Pero descubrí que la placa daplink_usb incluida con el readbear mk20 está ejecutando un chip stm32, han lanzado el firmware, que necesita cambiar una línea para que sea compatible con el cristal de 8 mhz (Detallado en la publicación del foro vinculada a continuación). De lo contrario cambia el cristal por uno de 16 mhz.

REPO DE GITHUB

Buen recurso del foro aquí .

Tenedor Redbear Github

Lo que hay que tener en cuenta es que un CMSIS DAP construido con una MCU de velocidad máxima es relativamente lento como costo del modo utilizado para la portabilidad; Las versiones comerciales con una velocidad decente son dispositivos USB de alta velocidad, no tanto por la velocidad de transferencia como porque entonces se permite un tamaño de paquete mayor. El protocolo ST-LINK hace un uso más eficiente del USB de alta velocidad, por lo que para un objetivo STM32 probablemente no desee reemplazar el firmware ST-LINK. También es posible flashear al menos algunas otras marcas a través de un ST-LINK no modificado con OpenOCD, por ejemplo, las tres generaciones de chips Nordic BLE.