Voltaje mínimo para evitar la corrupción de EEPROM para ATMega328P

5

Tengo un artilugio alimentado por batería con un ATMega328P con código Arduino que duerme la mayor parte del tiempo. Ocasionalmente necesita escribir algunos valores en la EEPROM. Funciona con batería, por lo que he intentado minimizar el consumo al deshabilitar el BOD, por lo que ahora tengo curiosidad acerca de qué rango de voltaje podría dañarse la EEPROM. ¿Alguien ha intentado ver qué tan bajo puede bajar el voltaje y aún así tenerlo seguro?

En la hoja de datos veo que hay opciones para BOD en 1V8. ¿Eso significa que sería seguro escribir EEPROM a 2V?

    
pregunta rslite

3 respuestas

6

Yo mismo he estado leyendo sobre AVRs; No soy el que más sabe, pero esto es lo que he recogido en mi investigación.

Primero, me doy cuenta de que está deshabilitando su BOD para ahorrar energía, pero esto se menciona como un método preventivo para evitar la corrupción de EEPROM en el ATmega328P. De la sección 8.4.2:

  

Mantenga el RESET AVR activo (bajo) durante períodos de potencia insuficiente   tensión de alimentación Esto se puede hacer habilitando el Brown-out interno   Detector (DBO).

Si está realmente interesado en desactivar el BOD, es posible desactivarlo cuando está en modo de suspensión. Para lograr esto, puede establecer el bit BODS en el registro MCUCR.

Al igual que usted, me he sentido frustrado por la ambigüedad en el voltaje con el que se corrompería la EEPROM del AVR. No veo nada en la ficha técnica. Sin embargo, citando el artículo Corrupción de la EEPROM de Atmel en su sitio web:

  

una secuencia de escritura regular en la EEPROM requiere un mínimo   voltaje para funcionar correctamente

¿Voltaje mínimo? Este es un artículo genérico, por lo que supongo que se refiere al voltaje más bajo al que opera el ATmega328P, que es 1.8V.

Espero haberte ayudado.

    
respondido por el Nick Williams
7

Como una adición a la respuesta aceptada:

Independientemente de las causas de la corrupción de EEPROM, siempre enfrenta el problema potencial que no puede completar al escribir una secuencia de bytes.
Considere un valor entero de 4 bytes. El BOD solo "garantizará" que no se producirá la corrupción de un solo byte, sin embargo, no evitará que el controlador se apague antes de que se haya escrito el valor total de 4 bytes, lo que corromperá efectivamente sus datos.

Para estar seguro, debe implementar algún tipo de mecanismo de "confirmación". Esto implicaría una suma de comprobación para verificar que sus datos son válidos y una copia duplicada de los datos, para asegurarse de que un conjunto de datos sea siempre válido. Si la suma de comprobación falla en el inicio, puede recurrir a la copia de seguridad. El conjunto de datos "válido y activo" se puede "marcar" con un solo byte.

    
respondido por el Rev1.0
4

Esto no es de ninguna manera una garantía, solo mi experiencia personal.

La hoja de datos proporciona un área de operación segura basada en la velocidad de reloj y el voltaje. Su límite se reduce de 4.5V a 20 MHz a 2.7V a 10 MHz.

Sin embargo, como uno de nuestros sistemas tiene interrupciones de alimentación y apagones varias veces por segundo por diseño, tuve la oportunidad de observar su comportamiento en condiciones en las que el apagón es un evento regular. Corriendo a 20 MHz con un nivel de DBO de 1.8 V, la corrupción de la actividad ocurrió con bastante regularidad, especialmente en las empresas no limpias. Al configurarlo a 2.7 V se solucionó esto y la corrupción del eeprom nunca ocurrió por encima de 2.7 V. (en la hoja de datos todavía no se encuentra en el área de operación segura, así que úselo bajo su propio riesgo) Cuando se usó con el oscilador interno de 8 Mhz, el nivel de BOD de 1.8 V fue suficiente, no se produjo corrupción del eeprom.

    
respondido por el vsz

Lea otras preguntas en las etiquetas