¿Existe el riesgo de que el HW depure un software integrado si la integridad de JTAG es mala?

Tuve que depurar un software integrado en C en un entorno ruidoso. Como resultado, la prueba de integridad de la conexión JTAG tuvo una tasa de fallas de entre el 30 % y el 60 %.

¿Cuáles son los riesgos de realizar accesos JTAG en tales condiciones? Quiero decir:

  • ¿Puedo quemar el microcontrolador?
  • ¿Es posible corromper la memoria no volátil para siempre?
  • ¿Existe un mecanismo de protección HW que proteja el chip? (evitando así cualquier acceso JTAG [actualización del programa, sesión de depuración, etc.])
  • ¿Es posible que los datos que muestra el depurador sean incorrectos?

El objetivo es una TI C2000. Pero preferiría una respuesta general si es posible.

Si sus herramientas de depuración son dudosas, entonces está jodido, en mi experiencia, el principal riesgo en su situación es que nunca podrá descubrir qué está pasando y seguirá depurando en 50 años.
@Will: Entonces, ¿quieres decir que mi pregunta #4 es al menos qué va a pasar?
En algunos casos, especialmente con MCU basadas en flash, es posible bloquearse el chip hasta el punto en que la reconexión es más difícil. Por ejemplo, una pieza STM32 recibirá ocasionalmente una mala carga que deshabilita la interfaz SWD (mini JTAG) y requiere la manipulación de la línea de reinicio durante la conexión, algo que generalmente no se necesita en esa serie. Mucho de esto dependerá de los detalles de implementación de un chip en particular. Definitivamente, también es posible tener un circuito circundante donde algunos estados son dañinos, por ejemplo, puentes H que pueden terminar con controladores de lado alto y bajo activados.
Si los datos en el depurador son incorrectos depende un poco de cosas como si se usan sumas de verificación en su configuración y no tengo idea de los detalles de lo que hacen sus herramientas. Pero sí sé que necesita una idea clara de lo que está pasando y algo en algún lugar del sistema en el que pueda confiar; de lo contrario, es extremadamente difícil establecer algo más allá de la duda y simplemente dará vueltas en círculos. la depuración se trata de averiguar qué es lo que va mal; la reparación suele ser un poco fácil
Las resistencias en serie (50-100 ohmios) pueden hacer magia para líneas de tipo jtag/spi/icsp, siempre vale la pena intentarlo
Intentaré leer más documentación y especificaciones sobre el tema. ¡Muchas gracias por esas respuestas de todos modos!

Respuestas (4)

Es poco probable que dañe la pieza, pero es posible que no pueda usar la conexión con éxito o de manera útil para depurar el dispositivo. Nunca estará seguro de que está viendo un error de software o una falla de su depurador, ya que algunos modos de falla pueden resultar en una falla de la interfaz de depuración en cualquier caso.

Los problemas de integridad de la señal a menudo se pueden resolver reduciendo la frecuencia del reloj JTAG. Esto afectará el rendimiento de la carga de software y los grandes volcados de memoria o las observaciones de datos, pero para el punto de interrupción simple y la depuración paso a paso seguirán siendo utilizables incluso a frecuencias relativamente bajas. Si ya está viendo un error del 60%, no será peor si reduce de 10 MHz a 4 MHz, por ejemplo, y puede caer a cero. Sugiero probar 1MHz como punto de partida. Si el rendimiento no es satisfactorio, puede intentar aumentarlo gradualmente para determinar la tasa máxima libre de errores, de manera similar, si aún obtiene errores, reduzca aún más.

En general, el cable JTAG debe ser lo más corto posible (<20 cm como guía), preferiblemente el cable original del fabricante de la sonda sin adaptadores ni extensiones.

Cuando se publicó esta pregunta en SO, agregó un comentario de que la sonda era una Blackhawk USB200 : el producto tiene un adaptador de aislamiento opcional para entornos hostiles para evitar problemas de bucle a tierra. Eso puede resolver su problema por completo.

Finalmente, ¿está seguro de que la tasa de error se debe al ruido? Un error bastante común es acceder a los pines utilizados para JTAG como GPIO en el software, por ejemplo.

Muchas gracias por este práctico consejo. No lo intentaré pronto, pero definitivamente lo haré cuando sea posible. Con respecto a su última pregunta: el JTAG es absolutamente perfecto fuera del sistema completo o en el sistema que usa una fuente de alimentación externa para la placa MCU. ¡Así que no creo en el software que usa los GPIO!
si el uso de una fuente de alimentación externa para la placa MCU marca la diferencia, quizás su problema esté en la conexión a tierra. Si su cable de tierra JTAG está roto, es posible que no vea problemas en una configuración (la tierra va a través de USB a la computadora portátil o algo así) y apenas en otra (tierras no conectadas flotando por todas partes)
@Plouff: A la luz de su comentario sobre trabajar con una fuente de alimentación externa, se aplica la sugerencia de Will sobre la conexión a tierra. He actualizado mi respuesta abordando esa posibilidad. Debe actualizar su pregunta con la información sobre la sonda que proporcionó en SO; sin embargo, edite la pregunta en lugar de agregarla como un comentario.

Agregando mis 2 centavos. ¡No se puede comentar!

Enfrentamos un problema similar con el mismo objetivo (C2000). Muy a menudo, el dispositivo se desconectaba y teníamos que reiniciar el IDE y actualizar el código nuevamente para depurar. Contactamos a TI y recibimos la siguiente sugerencia.

1) Use un aislador digital como este entre el depurador y el objetivo.

2) Reduzca la longitud del cable JTAG. Por lo general, el nuestro mide menos de 5 cm.

Funcionó muy bien.

Editar: Clifford ya señaló estas cosas. Solo agrego mi experiencia.

¡Tus 2 centavos valen mucho más! Hablaré sobre el aislador digital a mis colegios. ¡Espero que acepten esta solución para futuros diseños! ¡Muchas gracias a ti!

Absolutamente puede dañar el hardware.

Digamos que su cambio de IR se corrompe a una MCU o FPGA y accidentalmente carga EXTEST o ingresa una instrucción IEEE 1532 ISC, y no ha establecido valores seguros en las celdas BSR. Cada pin BSR en ese dispositivo afirmará inmediatamente cualquier estado que se encuentre en esas celdas.

Si tiene algunos dispositivos que ejecutan electrónica de potencia, por ejemplo, y no hay protección externa, podría disparar ambos MOSFET en un controlador de conmutación y corto voltaje directamente a GND. He visto que esto sucede varias veces. EXTEST es probablemente la instrucción más arriesgada que se define en la especificación.

Si no puede confiar en su configuración de JTAG, me detendría y solucionaría el problema antes de continuar. Incluso fuera del daño del hardware, piense en todo el tiempo de ingeniería que perderá persiguiendo Heisenbugs que resultaron ser un poco cambiantes de vez en cuando en un turno de DR.

Básicamente, mire su diseño y considere lo que sucede si cada pin en un dispositivo JTAG salta a un estado desconocido (o todos 0 o todos 1); es probable que no esté satisfecho con el resultado.

Otras cosas que he hecho en el pasado debido a la mala integridad de JTAG son la activación accidental de fusibles de seguridad y similares. Esto bloquearía la pieza y requeriría reemplazarla. Por diseño, JTAG no tiene verificación de integridad ni corrección de errores; es uno de los buses más simples posibles por diseño.

Muchas gracias por estos detalles técnicos y sus comentarios de acuerdo a su experiencia. Definitivamente eso es lo que me falta: experiencia. Pero al menos pensé que podría ser dañino. ¡Gracias, puedo entender por qué!

Si bien el daño físico directo al dispositivo de hardware parece poco probable, si un dispositivo incluye algún tipo de fusibles de configuración de escritura única, existe una probabilidad muy real de que una conexión JTAG ruidosa pueda causar que dicho fusible se configure erróneamente de una manera que el chip permanentemente inútil. Además, muchos procesadores se utilizan de formas que podrían causar daños en el circuito de la CPU u otro hardware si los pines de E/S se configuraran en condiciones erróneas.

Básicamente, me imagino que una conexión JTAG ruidosa podría hacer que el sistema crea erróneamente que le está dando cualquier combinación de comandos y datos que sería la más peligrosa. Si no hay nada que alimente al dispositivo que sea particularmente dañino, entonces nada se dañará. Pero si fuera posible dañar deliberadamente el dispositivo utilizando el JTAG, se debe suponer que dicho daño también podría ocurrir accidentalmente a menos que se hayan realizado esfuerzos sistemáticos para evitarlo.

Muchas gracias por sus comentarios. En el trabajo algunas personas me dijeron que no debería ser un problema. Confirmaste mi temor: se debe tener mucho cuidado cuando se trata de JTAG. Intentaré encontrar una solución...
@Plouff: Hay momentos en los que se requiere un 100 % de confiabilidad; hay otros donde el 99% de confiabilidad es más que adecuado. Dado que el 99 % de confiabilidad suele ser más fácil de lograr que el 100 %, ser capaz de reconocer cuándo es lo suficientemente bueno a veces puede ser muy útil.
Sí, definitivamente estoy de acuerdo con tu punto de vista. Si puedo alcanzar el 99% de confiabilidad, estaré más que feliz. Pero me mantuve por debajo del 70% y alrededor del 50% la mayor parte del tiempo... ¡Así que pensé que había algo que hacer al respecto!