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:
El objetivo es una TI C2000. Pero preferiría una respuesta general si es posible.
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.
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.
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.
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.
Voluntad
arado
chris stratton
Voluntad
Voluntad
arado