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

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

Respuesta Con la alimentación aplicada, los pines sin alimentación se leen entre 50 mV y 300 mV. Una vez más, este es un uC no programado, por lo que no hay ningún código en ejecución. 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ó utilizando el programador AVR JTAG ICE 3, se detectó el microcontrolador y leyó la firma y los fusibles a la perfección. Si bien AVR Dragon es técnicamente compatible con PDI, puede necesitar resistencias adicionales de pull-up / pull-down o tener otros requisitos de circuito para funcionar como se espera.

Aquí hay muchas sugerencias excelentes, así que léalas todas si está experimentando el mismo problema.

También tenga en cuenta: enlace Hasta la Revisión K del A3 / D3 Los Xmega no son compatibles con AVR Dragon. (8-17-2012)

Mi siguiente paso sería instalar los condensadores electrolíticos como se recomienda en la Lista de verificación esquemática que mencionó. Si todavía no funciona, Seguiría adelante e instalaría todos los inductores, etc. recomendados en la lista de verificación - tal vez hay una razón por la cual Atmel publicó esa lista de verificación :-).

Si aún no funciona, recurriría al tipo de errores que a menudo cometo:

• Cuando pruebo los pines de alimentación VCC y AVCC con un multímetro, ¿todos y cada uno de ellos muestran que tengo los 3.3 V correctos?
• ¿Todos y cada uno de los pines GND están bien conectados a GND?
• ¿Tal vez instalé el conector PDI al revés o al revés otra vez ? ¿O tal vez olvide conectar uno de sus pines a la MCU? (Use un multímetro para sonar la conexión, una sonda directamente en el pin del chip MCU, la otra en el extremo del cable a la parte de programmer al que se debe conectar el pin)
• ¿He usado la señal acústica del multímetro para confirmar que no he enganchado dos pines adyacentes?
• ¿Hay algún problema con el programador Dragon o el cable entre éste y la placa? ¿Funciona el programa Dragon justo cuando lo uso para programar algún otro chip AVR similar, tal vez un chip de agujero pasante embutido en una placa de pruebas sin soldadura?

¿Podrías publicar una foto de tu PCB?

Con la mayoría de los dispositivos electrónicos digitales, incluso si se sabe que el PCB es incorrecto, generalmente es más rápido y más fácil cortar rastros y agregar cables de puente en el prototipo hasta que al menos llegue a la etapa de "parpadear un LED" que esperar a otro PCB para ser fabbed que tiene menos problemas con él.

La longitud de traza adicional de 10 mm 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 no hay cortocircuitos entre rastros adyacentes, y el programa aún no "reconoce" el chip, solo así concluiré el chip es un error y conseguir 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 cambiará para mostrarme que está bien? ¿Una especie de hardware "Hola mundo"?

Sí. Parpadeo de un LED se considera el equivalente de "Hello World" en electrónica. a b c d Sin embargo, esto no sucede automáticamente: necesitas conectar un pin a un LED y escribir un 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 parpadear un LED "latido" a b que una vez por segundo aproximadamente. Eso hace que sea casi instantáneo para confirmar que el programa está cargado y en ejecución, La frecuencia correcta de 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 se está ejecutando con el último código en lugar del código antiguo).

No, una diferencia de longitud de 10 mm no causará problemas; vale la pena un retraso de alrededor de 50 ps, 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 extrañas si inesperadamente vería un bloque de Flash no programado o inexistente. El contador del programa lo ejecutará hasta que llegue a 0xFFFF, envuélvalo a 0x0000 para llegar al vector de reinicio. Esto depende de su controlador. Si se borra no verás que pase nada. Si 0xFF sería el código para otra instrucción, cualquier cosa puede pasar, pero sería muy afortunado ver actividad en los pines de E / S.

También pueden contener un programa de prueba utilizado en la producción. Puede desmontarlo si realmente quiere saber lo que hace, supongo que ejecutará un algoritmo con 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 como ese.

El sitio web oficial de Atmel dice:

  

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

enlace

De AVR App Note 1005:

  

5.1 Requisitos de diseño de hardware para hacer funcionar el PDI

     

La interfaz PDI es una interfaz UART semidúplex síncrona. Las dos lineas,   PDI_DATA y PDI_CLK, por lo tanto, deben estar equilibrados. Si colocas un pull-up fuerte.   y tapa de desacoplamiento en el PDI_CLK, que también es la línea de reinicio, el reloj y los datos   ya no se sincronizará correctamente Por lo tanto, durante el desarrollo usted debe   retire cualquier capacitor de pull-up y desacoplamiento. Esto también se aplica si se utiliza el PDI   Interfaz 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?

La interfaz pdi pone el microcontrolador en reinicio, por lo tanto no programado o programado, una vez que lo reinicies, 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, la longitud de su cable / traza probablemente no sea un problema. Pero si hace una pausa demasiado larga en un ciclo de reloj, la parte sale automáticamente del modo de programación y debe comenzar todo de nuevo. Hay una secuencia de inicio que tiene que suceder. por ejemplo, si lees una ubicación de memoria / flash, luego dejas de imprimirlo, luego regresas, es posible que hayas tardado demasiado y tengas que reiniciar. no es difícil en absoluto bang xmega pdi, ¿lo has intentado en lugar de usar algún otro programador que intenta ser de talla única (lo que nunca encaja bien con nadie)?