¿Cuál es el comportamiento de un MicroControlador no programado?

Problema: Recibo errores cuando intento conectarme al MicroController usando la interfaz PDI. ¿Cómo se comporta un MicroControlador cuando no ha sido programado? ¿Hay un pin que alternará para mostrarme que está bien? ¿Una especie de hardware "Hello World"?

Me gustaría una forma de confirmar si el MicroController ha fallado o si he hecho algo más mal.

Información Adicional:

Diseñé y fabricé una placa personalizada para un microcontrolador Atmel XMEGA, ATXMega64D3 para ser exactos. Estoy usando ATXMega192D3 para la creación de prototipos, pero estos chips son idénticos excepto Flash/SRAM/EEPROM.

En este punto, la fuente de alimentación es una fuente de alimentación de placa de prueba 3V3 verificada y estable para todos los pines de alimentación del microcontrolador y los pines de alimentación del conector PDI. Tengo la mayoría de las tapas de desacoplamiento recomendadas en AVR1012 : XMEGA A Schematic Checklist, sección 2.1. Coloqué puentes en lugar de los inductores y perlas especificados, y no instalé los condensadores electrolíticos.

Total de piezas instaladas = 6 tapas de desacoplamiento de 100 nF, 1 microcontrolador, cabezal de 6 pines para PDI.

El MicroController es un TQFP de 64 pines que soldé a mano con un aumento de 7-14x. Luego inspeccionado en busca de puentes de soldadura.

Vivo en el área de Seattle y ha estado lloviendo, soy nativo, así que no encendí la calefacción. Las probabilidades de daño estático son muy bajas.

El programador es un AVR Dragon, que utiliza la versión más reciente (no beta) de Atmel Studio 6.0. Que lee el nivel de potencia de las placas correctamente pero en realidad no puede comunicarse con el MicroController.

Mi teoría actual:

Revisé mi diseño y el trazo del reloj PDI tiene 15 mm de largo y el trazo de datos PDI tiene 25 mm de largo, ¿es esta una diferencia suficiente para causar problemas de sincronización? Me gustaría una forma de confirmar esto antes de gastar tiempo y dinero en hacer una nueva placa.

Gracias por cualquier ayuda o idea.

Actualizar Aún no funciona, pero encontré y solucioné los siguientes problemas.

  • El MicroController se instaló a 180 grados de lo requerido. El uC que tengo tiene 2 círculos en las esquinas diagonales. Cuando lo instalé por primera vez, orienté el círculo más grande para alinearlo con mi Sikscreen. Solo más tarde, cuando leí el logotipo, me di cuenta de que cuando el logotipo está orientado correctamente, el identificador del pin n.º 1 (círculo más pequeño) está en la parte superior izquierda.
  • Debido a que comencé con el regulador de voltaje en la placa, mi fuente de alimentación se configuró en 5 V, que está más allá del voltaje máximo para este chip. Así que reemplacé el MicroController con un extra que compré al mismo tiempo.

En este momento, mi teoría es que el AVR Dragon es mi problema. La documentación indica que Dragon puede conectarse a XMega con PDI, pero he encontrado varios comentarios que parecen mostrar una tasa de éxito del 30 %, según el modelo de XMega.

Como FYI con energía aplicada, los pines que no son de alimentación leen entre 50 mV y 300 mV. Una vez más, este es un uC no programado, por lo que no se está ejecutando ningún código. Esto podría ser un voltaje de fuga o podría ser la configuración predeterminada de los pines, no estoy seguro.

Solución

Usando el programador AVR JTAG ICE 3 apareció, lee la firma y fusiona perfectamente.

Me parece recordar que puede bajar la velocidad del reloj en el programador PDI, ¿lo ha intentado? Los AVR no programados usan el oscilador interno por configuración de fusible predeterminada (creo que 1 o 2 MHz) de fábrica, y se supone que debe limitar la frecuencia de programación a una fracción de eso. Además, dado que tiene un Dragón, ¿por qué no intenta usar la interfaz de programación ISP de 6 pines? Su uso está mucho más extendido.
El ATMega*D3 solo admite PDI, no ISP, no JTAG. Además, debido a que la vista de la interfaz AVRDragon en Atmel Studio no tiene una opción de velocidad, creo que se debe a que PDI proporciona su propio reloj. Probé el AVRDragon con una placa ATMega16 usando ISP y funcionó como se esperaba, así que vi la configuración a la que te refieres.
Debo estar recordando mal, lo siento
@James: publique su solución como respuesta. Puedes aceptarlo en unos días. No obtendrá un representante por ello, pero otros verán de inmediato que la pregunta está respondida.

Respuestas (6)

Mi próximo paso sería instalar los capacitores electrolíticos como se recomienda en la Lista de verificación esquemática que mencionó. Si aún no funciona, continuaría e instalaría todos los inductores, etc. recomendados en la lista de verificación; tal vez haya una razón por la que Atmel publicó esa lista de verificación :-).

Si todavía no funciona, recurriría a los tipos de errores que suelo cometer:

  • Cuando pruebo los pines de alimentación VCC y AVCC con un multímetro, ¿muestran todos y cada uno de ellos que tengo los 3,3 V correctos?
  • ¿Están todos y cada uno de los pines GND conectados sólidamente a GND?
  • ¿Quizás volví a instalar el conector PDI al revés o al revés ? ¿O tal vez se olvidó de conectar uno de sus pines a la MCU? (Use un multímetro para emitir un pitido en la conexión, una sonda directamente en el pin del chip MCU, la otra en el otro extremo del cable a la parte del programador a la que se supone que debe estar conectado ese pin)
  • ¿He usado el zumbador del multímetro para confirmar que no he cortado dos pines adyacentes?
  • ¿Hay algún problema con el programador Dragon o con el cable entre este y la placa? ¿Funciona bien el programa Dragon cuando lo uso para programar algún otro chip AVR similar, tal vez un chip de orificio pasante metido en una placa de prueba sin soldadura?

¿Podrías poner una foto de tu PCB?

Con la mayoría de los dispositivos electrónicos digitales, incluso si se sabe que la placa de circuito impreso es incorrecta, generalmente es más rápido y más fácil cortar los rastros y agregar cables de puente en el prototipo hasta que al menos llegue a la etapa de "parpadeo de un LED" que esperar a que se active otra placa de circuito impreso. ser fabuloso que tiene menos problemas con él.

10 mm de longitud de trazo extra es irrelevante en esta aplicación. Estoy casi seguro de que ese no es el problema.

Después de asegurarme exhaustivamente de que todo esté conectado correctamente, según lo recomendado por el fabricante, y que no haya cortocircuitos entre los rastros adyacentes, y el programa aún no "reconoce" el chip, solo entonces concluiría que el chip es un fiasco. y obtener un chip de reemplazo.

Más tarde, después de que el programador "reconozca" el chip y comience a programarlo, puede pensar en:

¿Hay un pin que alternará para mostrarme que está bien? ¿Una especie de hardware "Hello World"?

Sí. Hacer parpadear un LED se considera el equivalente de "Hello World" en electrónica. a b c d Sin embargo, esto no sucede automáticamente: debe conectar un pin a un LED y debe escribir algún código para que parpadee.

Incluso después de que una persona programa los otros pines para hacer cosas útiles, a menudo dejan el código para que parpadee un LED de "latido" una vez por segundo más o menos. Eso hace que sea casi instantáneo confirmar que el programa está cargado y funcionando, que la frecuencia correcta del cristal está conectada, etc. (Algunas personas cambian deliberadamente la velocidad de parpadeo cada vez que reprograman el chip, solo para asegurarse de que el chip ahora está ejecutándose con el código más reciente en lugar del código anterior).

No, una diferencia de longitud de 10 mm no causará problemas; vale la pena un retraso de aproximadamente 50ps o 0.05ns.

Los microcontroladores no programados a veces se borran para que toda la memoria del programa lea 0xFF. Lo que sucede si ejecuta esto depende de su controlador. Algunos controladores tienen 0xFF como código de máquina para un NOP, por lo que el controlador no hace cosas raras si inesperadamente ve un bloque de Flash no programado o inexistente. El contador del programa lo recorrerá hasta que llegue a 0xFFFF, vuelva a 0x0000 para llegar al vector de reinicio. Esto depende de su controlador. Si se borra, no verá que suceda nada. Si 0xFF fuera el código para otra instrucción, cualquier cosa podría pasar, pero sería muy afortunado ver actividad en los pines de E/S.

También pueden contener un programa de prueba utilizado en producción. Puede desarmarlo si realmente quiere saber lo que hace, supongo que ejecutará un algoritmo que involucre tantas instrucciones diferentes como sea posible y activará alguna salida cuando el algoritmo se ejecute correctamente (también se usarán otras E/S en el proceso).

También es posible que no se haya borrado y que contenga basura. Nunca he tenido controladores así.

Algunos controladores están programados de fábrica con un cargador de arranque (muy bueno). Otros, cuando están en blanco, ejecutarán código secuencial hasta que "caigan al final", pero luego harán cosas indeseables después de que eso suceda (por ejemplo, intentar usar un montón de pines de E/S como un bus de memoria). Recuerdo un dispositivo basado en 68HC05 en el que tuve que trabajar que sacudiría su E/S salvajemente si se caía al final del espacio del código y también provocaba un reinicio instantáneo de una PC con Windows 3.1 (basada en 386sx) que estaba conectada a su UART. Eso fue molesto. El chip "perro guardián" estaba conectado a una de las E/S que golpeaban salvajemente, por lo que estaba feliz.
@supercat: un cargador de arranque, ¿no estaría en ROM en lugar de Flash? (Adivinando, no lo sé.)
@stevenvh, esa distinción se vuelve complicada, cuando la ROM se crea con memoria Flash, las personas a menudo comienzan a usar Flash para referirse a ROM y todavía hay flash adicional para el uso del tiempo de ejecución por parte del chip. Conozco a muchos que dicen flash en lugar de ROM para disgusto de los más experimentados. Supongo que vive y deja vivir en eso.
@Kortuk: no me importa si lo implementan como Flash, cuando digo ROM me refiero a que no se puede borrar. En general, ¿están protegidos esos cargadores de arranque?
@stevenvh, que yo sepa, puede programar directamente sobre los cargadores de arranque en AVR, pero podría estar equivocado, AVR no es mi área. Soy más un tipo MSP430 y PIC. Que yo sepa, los PIC no tenían cargador de arranque (tengo un buen programador) y los MSP430 que he usado tenían uno en algunas de las versiones, pero se pueden programar si está dispuesto a forzar el uso de un programador en lugar de simplemente cargar el arranque. USB sin hardware adicional.
@stevenvh, normalmente el flash utilizado para los programas no es modificable por el chip durante la operación y requiere un programa, pero esto es algo que varía enormemente con los productos que yo sepa. El MSP430 podía editar pero era más trabajo. Sigo pensando que su respuesta es válida, solo agregando algo de claridad si puedo.
@stevenvh, un cargador de arranque es solo el primer bit de código que se ejecuta después del reinicio del dispositivo y su función típica es cargar una nueva aplicación de usuario a través de alguna interfaz externa (usb, ethernet, etc.). Si ese bit de código reside en un segmento de memoria escribible o no parece fuera de lugar, ¿no? En los AVR, solo puede emitir instrucciones de autoprogramación desde el segmento del cargador de arranque de flash. El segmento del gestor de arranque en sí mismo se puede volver a escribir con un programador ISP.
@vicatcu, estaba respondiendo la pregunta de steven. Estaba diciendo que los cargadores de arranque en general no están protegidos y compartiendo mi confianza en mi conocimiento de eso, admito que nos desviamos un poco.
@vicatcu: creo que es relevante si se puede escribir o no. Si accidentalmente sobrescribe/borra su cargador de arranque, pierde esa forma de programar el dispositivo.
@stevenvh Acepto su punto... en cualquier caso, la interfaz PDI en los AVR es una interfaz de programación de hardware que no depende de un cargador de arranque de todos modos
@stevenvh: algunos chips que permiten modificar flash mediante el código que se ejecuta en RAM, incluidos algunos TI DSP y algunas variantes 68HC05 (estoy seguro de que hay muchos otros, pero estoy familiarizado con ellos), se envían con un cargador de arranque en flash que leerá el código de un puerto serie en la RAM y lo ejecutará. Ese código, a su vez, se puede usar para programar el flash con cualquier imagen de código deseada, sin requerir que el fabricante use ningún espacio de matriz para la ROM ni para el hardware para permitir la programación con un número bajo de pines.
@stevenvh: el código de usuario puede optar por dejar el cargador de arranque como está (lo que permite actualizaciones de código fáciles) o reemplazar el cargador de arranque con el código de usuario (que puede contener o no un cargador de arranque propio). Si el cargador de arranque suministrado de fábrica se sobrescribe y el código de usuario no contiene algún tipo de cargador de arranque que funcione, es posible que no se puedan realizar futuras actualizaciones de firmware (excepto reemplazando el chip por uno que tenga un cargador de arranque que funcione).

La pregunta general de "¿Cuál es el comportamiento de un MicroControlador no programado?"

Respuesta Con alimentación aplicada, los pines que no son de alimentación leen entre 50 mV y 300 mV. Una vez más, este es un uC no programado, por lo que no se está ejecutando ningún código. Esto podría ser un voltaje de fuga o podría ser la configuración predeterminada de los pines, no estoy seguro.

Mi situación específica se resolvió usando el programador AVR JTAG ICE 3, se detectó el MicroController y leyó la firma y fusiona perfectamente. Si bien el AVR Dragon puede ser técnicamente compatible con PDI, es posible que necesite resistencias pull-up/pull-down adicionales o que tenga otros requisitos de circuito para funcionar como se espera.

Hay muchas sugerencias excelentes aquí, así que léalas todas si tiene el mismo problema.

También tenga en cuenta: http://www.atmel.no/webdoc/atmelstudio/supported.devices.notes.1.html Hasta la revisión K de A3/D3 Xmega no son compatibles con AVR Dragon. (17-8-2012)

El sitio web oficial de Atmel dice:

Problemas de XMEGA PDI: el modo XMEGA PDI en AVR Dragon NO funciona para los siguientes dispositivos XMEGA: A3/D3 - revisiones B, C y E o A1 (hasta la revisión K)

http://www.atmel.com/webdoc/avrdragon/avrdragon.known_issues.html

De la nota 1005 de la aplicación AVR:

5.1 Requisitos de diseño de hardware para que PDI funcione

La interfaz PDI es una interfaz UART semidúplex síncrona. Por lo tanto, las dos líneas, PDI_DATA y PDI_CLK, deben equilibrarse. Si coloca una tapa fuerte de pull-up y desacoplamiento en PDI_CLK, que también es la línea de reinicio, el reloj y los datos ya no se sincronizarán correctamente. Por lo tanto, durante el desarrollo, debe quitar los condensadores de desacoplamiento y pull-up. Esto también se aplica si se usa la interfaz PDI para la programación en el sistema del XMEGA en producción.

¿También ha conectado el dispositivo al encabezado de programación según esta imagen?

ingrese la descripción de la imagen aquí

Este es el documento/huella, basé el mío y ya lo he revisado varias veces, pero por el momento no estoy 100% en los pines PDI, así que lo revisaré nuevamente. Gracias.
podría ayudar si publicara los aspectos relevantes de los esquemas y el diseño
Verifiqué este conector y es correcto. Es difícil aislar esta parte de mi esquema y diseño, también quería intentar hacer esta pregunta un poco más genérica para que pudiera ayudar a más personas que solo a mí.

La interfaz pdi pone el microcontrolador en reinicio, por lo que no está programado o programado, una vez que reinicias, no importa. Si tuviera la parte al revés, podría haberla frito u otras cosas, incluido su programador, por lo que todo es sospechoso en este punto.

el protocolo pdi, al menos en el xmega (atmel puede tener dos diferentes, ambos llamados pdi) que programé, definitivamente tiene restricciones de tiempo en el reloj, es probable que las longitudes de su cable/traza no sean un problema. Pero si hace una pausa demasiado larga en un ciclo de reloj, la pieza sale automáticamente del modo de programación y tiene que empezar de nuevo. hay una secuencia de inicio que tiene que suceder. por ejemplo, si lee una ubicación de memoria/flash y luego se detiene para imprimirla, luego regresa, es posible que haya tardado demasiado y tenga que reiniciar. no es difícil en absoluto hacer bit bang xmega pdi, ¿has probado eso en lugar de usar algún otro programador que intenta ser un tamaño único para todos (que nunca le queda bien a nadie)?

¿Cuál es el comportamiento de un MicroControlador no programado?
RespuestasAquíPolítica de privacidad1y, 0v