Tengo dos placas diferentes que ejecutan el mismo código con el mismo chip (ATMega32u4).
Resumen del problema
El problema es que la segunda placa parece perder el programa que se ha enviado al chip si pierde energía.
Ambas placas tienen conectores mini USB y obtienen energía de USB y ambas funcionan a 5v.
Primera Junta (de Trabajo)
La primera placa es una SparkFun Pro Micro "oficial".
Segundo tablero (defectuoso)
El segundo tablero es una imitación de ese tablero que compré en Amazon. Puede ver los detalles de esa placa en: Placa de imitación Pro Micro en Amazon
NOTA : No espero que nadie examine perfectamente esos tableros y me diga el motivo exacto. Solo estoy agregando esa información en caso de que alguien note algo completamente diferente que indique el problema.
Programando las Tarjetas
Cuando programo las placas, configuro el Arduino IDE en la placa Pro Micro a 5v y 16Mhz y el programa funciona igual de bien en ambas placas. Luego ejecuto el tablero de imitación y funciona perfectamente. Es un pequeño programa que recibe datos de bluetooth y muestra los datos en otro lugar.
Pérdida de energía, pérdida de programa flasheado
En la primera placa, la programé una vez hace semanas y funciona después de estar apagada durante días. Obviamente, esa es la forma en que se supone que debe funcionar.
En la segunda placa, si pierde energía, parece perder el programa.
¿Cosas comunes para verificar?
Me pregunto si hay algunas cosas comunes que pueda verificar para determinar por qué el programa parece haberse perdido.
¿Hay cosas obvias que me estoy perdiendo? ¿Es posible que el fabricante no haya conectado algo correctamente que podría causar esto? Quiero decir, ¿es este un problema común con la fabricación de placas? Tengo 5 de estas placas de imitación y he probado dos hasta ahora y ambas parecen tener el problema.
Cualquier ayuda es muy apreciada.
Editar: información adicional
Encontré la siguiente información en una revisión en Amazon:
Al igual que algunos otros revisores, mi Pro Micro parecía estar perdiendo el boceto cuando se desconectó de la alimentación. Sin embargo, ahora me he dado cuenta de que Pro Micro en realidad no está perdiendo el boceto, hay un problema completamente diferente. Cuando el Pro Micro se vuelve a conectar a la alimentación, por alguna razón, el cargador de arranque no está ejecutando el boceto. Si luego realiza un reinicio suave conectando el pin RST a tierra, al reiniciar, el cargador de arranque comienza a ejecutar el boceto con éxito.
Entonces, el problema se puede solucionar conectando un botón al pin RST y presionando el botón cada vez que conecta el Pro Micro para que se reinicie y ejecute el boceto. Es molesto que el problema exista, pero al menos es viable.
¿Alguien puede explicar este fenómeno?
Sí, el cargador de arranque instalado simplemente espera un nuevo boceto indefinidamente, sin agotar el tiempo y sin ingresar al existente después de un cierto período.
¿Podría haber otra solución que sea una solución automatizada, en lugar de presionar un botón cada vez?
Instale un nuevo gestor de arranque. Tengo un boceto descrito en mi página sobre la grabación de cargadores de arranque que instala el cargador de arranque Leonardo. Creo que el cargador de arranque Pro Micro es similar o idéntico (después de todo, es el mismo chip).
Solo necesita una segunda placa (su otro Micro serviría) para usar para la programación. El cableado para un Leonardo se describe en mi página; sin embargo, consulte a continuación para el Micro. El código está en los bocetos de Arduino en GitHub , en particular en el directorio "Atmega_Board_Programmer".
Debe conectar las dos placas de la siguiente manera:
SCK <--> SCK (pin labelled 15 on the Pro Micro board) *
MISO <--> MISO (pin labelled 14 on the Pro Micro board)
MOSI <--> MOSI (pin labelled 16 on the Pro Micro board)
VCC <--> VCC
Gnd <--> Gnd
D10 <--> Reset (pin labelled 10 on the programming board to Reset on the
board to be programmed)
* Por lo que puedo decir de su foto y el esquema
Posiblemente (probablemente) después de instalar el cargador de arranque, la placa se identificará en su PC como Leonardo y no como Micro, pero eso no importa ya que es el mismo chip subyacente.
Bueno, las MCU atmega están basadas en flash, por lo que nunca deberían "perder el programa" sin un ciclo de borrado explícito. Sin embargo, es posible que algo esté impidiendo que el chip inicie su programa. ¿Ha intentado leer el programa almacenado en el chip después de apagar y encender la placa y compararlo con el original? Si coincide, esto descartará que el programa se 'pierda'. Eso deja un par de posibilidades. Uno es un problema con el circuito de reinicio que impide que el chip salga del reinicio hasta que se conecte el cable USB y se inicie el software de programación. Otro posible problema es que el chip tiene instalado un gestor de arranque defectuoso que no inicia automáticamente el código de usuario. Esa podría ser una solución bastante simple, simplemente actualice el cargador de arranque correcto usando un programador ISP u otra placa que Está configurado para actuar como un programador ISP. Otra posibilidad es que el chip en sí sea una imitación... en cuyo caso todas las apuestas están canceladas.
Tengo un programador usbasp, así que después de leer la excelente respuesta de @nick-gammon y sonaba como si solo necesitara actualizar un nuevo gestor de arranque en mis placas de imitación, quería probarlo.
No sabía exactamente lo que tenía que hacer, así que decidí ir y hacerlo rápido.
Al principio, navegué por el excelente sitio web de @nick-gammon y encontré el gestor de arranque de leonardo, pero me di cuenta de que no era un archivo .hex directo, así que cuando lo probé y obtuve un error, pensé que no iba a funcionar. trabajo para mi configuración.
configuración de hardware
En primer lugar, tengo un conector de 10 pines en mi programador usbasp que se parece a lo siguiente:
Así es como se ve mi cableado de hardware en la placa de imitación. Es una imagen fea, pero al menos la he etiquetado.
Un par de cosas a tener en cuenta son que @nick-gammon mencionó que D10 sería el reinicio, pero en mi caso no lo es. En cambio, puede ver que mi línea de reinicio estaba conectada al pin RST en el tablero que está justo encima del VCC. Y sí, los colores de los cables son extremadamente confusos para el VCC y el RST, pero las etiquetas son correctas.
Obtener el archivo hexadecimal del cargador de arranque Como mencioné en mi pregunta original, quería que estas placas de imitación funcionaran como mi SparkFun Pro Micro original (más cara). Revisé el sitio de sparkfun y me proporcionaron el cargador de arranque que usaron. Eso es muy bonito y tuve suerte de poder conseguirlo. Puede obtenerlo en: https://www.sparkfun.com/products/12640 y luego hacer clic en el enlace Arduino Addon Files . Obtendrá un archivo zip y luego puede descomprimirlo y buscar en la carpeta \sparkfun\avr\bootloaders\caterina\ y encontrará un archivo .hex llamado: caterina-promicro16.hex. Estaba suponiendo que este sería el archivo del gestor de arranque.
Flashear el cargador de arranque usando AVRDude
Después de todo eso, fui a la línea de comando y encendí AVRDude. Le di el siguiente comando (asegurándome de tener el archivo caterina-promicro16.hex disponible en el mismo directorio, por supuesto).
avrdude -c usbasp -p m32u4 -U flash:w:Caterina-promicro16.hex
Si todo está cableado correctamente, verá lo siguiente cuando el cargador de arranque se muestre en su ATMega32u4.
Cuando vi todo eso me emocioné! Pero, todavía no podía estar seguro de que esto iba a resolver mi problema. Para hacer eso, tuve que abrir Arduino IDE y flashear en mi programa original.
Seguí adelante e hice eso y probé el programa. Funcionó.
Desenchufe y vuelva a intentarlo
Después de eso, necesitaba desconectar la placa de imitación y ver si perdería el programa, o si simplemente lo cargaría como debería. Lo probé y funcionó muy bien, así que lo desconecté varias veces y funcionó siempre. Mi programa siempre se está ejecutando ahora como esperaba que fuera.
Además, compré 5 de estas placas de imitación y las estoy cargando, dos hechas hasta ahora y ambas funcionan fantásticamente.
Gracias por toda tu ayuda @nick-gammon.
Nick Gammon mentioned that D10 would be the reset
- no entendiste ese bit. D10 en el tablero de programación se conecta a Restablecer en el tablero de destino , por lo que al conducir D10 bajo, el programador reinicia el tablero de destino.I found the leonardo bootloader, but I could tell it wasn't a straight up .hex file
- los gestores de arranque están en la descarga IDE. Busque en la carpeta "cargadores de arranque". En la carpeta "caterina" hay un archivo Leonardo-prod-firmware-2012-12-10.hex
, que es el archivo .hex del gestor de arranque de Leonardo. Para el Micro sería Micro-prod-firmware-2012-12-10.hex
.Sí, noté un problema similar con mis antiguas placas AT89s52, algunas veces la placa de desarrollo actúa muerta y vuelve a funcionar después de un reinicio.
No estoy seguro, pero la fuente de alimentación puede contener picos de voltaje o algunos ruidos que pueden hacer que la MCU actúe como muerta. Esto puede suceder porque los capacitores no pueden filtrar esos picos al principio usando un adaptador bien regulado (adaptadores de alta calidad) que puede resolver el problema. y también use un poco de IPA y limpie toda la tabla.
Como otros amigos sugirieron, pruebe también con las cosas del gestor de arranque.
chris stratton
Raddevus
usuario2943160