ATmega328P que se ejecuta en CR2032 tiene problemas con el código de sincronización/reposo ya que el voltaje se deprecia con el tiempo

Tengo un ATmega328P funcionando a 16 Mhz en CR2032 con algunos sensores y radio desde hace una semana. Comenzó con más de 3 voltios y actualmente mide 2,96 voltios. Actualmente, no estoy usando reguladores de impulso para regular esto. Utilizo el modo de suspensión de bajo consumo con las bibliotecas jee lib , duermo durante unos segundos y luego me despierto durante menos de un segundo, tomo algunas lecturas, transmito y vuelvo a dormir nuevamente.

Últimamente, noté que la duración del sueño se había reducido en algunos órdenes de magnitud. Parece dormir durante aproximadamente 50 milisegundos, en lugar de los 5 segundos de sueño en los que solía trabajar. Si cambio a 2xAA (2,84 voltios), sigo teniendo el ciclo completo de suspensión de 5 segundos.

¿Este comportamiento se debe a que el ATmega328P volvió a usar los 8 MHz internos en lugar de los 16 MHz externos? ¿Tampoco está seguro de cómo funciona bien la temporización/reposo con 2xAA a 2,84 voltios pero no con CR2032 a 2,96 voltios?

En lugar del sueño previsto, es posible que experimente un ciclo repetitivo de caída de tensión y reinicio. Intente observar el voltaje de suministro con un alcance.

Respuestas (2)

Unas pocas cosas. Lo más probable es que esté midiendo la batería sin carga. Incluso si está conectado y en funcionamiento, un multímetro no detecta consumos rápidos de energía. Se necesita un osciloscopio para consumos de energía de milisegundos. Recuerde, los CR2032 están diseñados para uso a largo plazo con baja corriente. 250 mAh a unos pocos mA. El micro y los sensores que salen del modo de suspensión provocan una irrupción, y la alta ESR (resistencia en serie equivalente) del CR2032 provoca una caída de tensión. ¿Tiene un condensador de desacoplamiento en paralelo cerca de los pines de alimentación?

Y las caídas de voltaje no harán que el ATmega baje a una velocidad más lenta. Esa es una característica demasiado avanzada para la mayoría de los micros humildes. Seguirá intentando funcionar a 16 MHz, con un reloj inestable. Es probable que se produzcan apagones.

Puede ejecutar el ATmega a 8 MHz para todos los voltajes para evitar el problema y ajustar sus retrasos/temporizadores en función de eso.

Gracias por la info. Sí, los voltajes se midieron sin carga. Probé algunos condensadores de desacoplamiento: 1uF, 10uF (no pude obtener 0.1uF) pero no cambiaron el comportamiento de salida. Utilizo la radio nrf24l01+ de baja potencia y el sensor tmp36... y parecen tener necesidades de corriente muy bajas. Actualmente, ATmega328p-pu ejecuta el cargador de arranque Arduino Uno. ¿Sabría que si uso el cargador de arranque de 8 MHz podría seguir usando los mismos comandos de ATmega que utilizan los modos de suspensión de bajo consumo ( jeelabs.net/pub/docs/jeelib/classSleepy.html )?
Debería, simplemente dividir sus tiempos de retraso esperados por la mitad y luego probar. (La mitad del reloj, se tarda el doble en contar hasta el mismo número)
Aquí un artículo sobre un proyecto que usa un CR2032 como fuente de energía: hackster.io/Talk2/…

Parece que está ejecutando la MCU fuera del área de operación segura con una celda de moneda. De acuerdo con la hoja de datos de ATmega328P , página 316, el voltaje de suministro seguro mínimo para 16 MHz es de alrededor de 3,8 V (las marcas rojas son mías). Debería esperar ver un comportamiento errático en ese caso. En la práctica, solo está haciendo overclocking en su MCU. Vea lo que Russell McMahon tiene que decir al respecto .

Área de operación segura ATmega328P

En cuanto a la pregunta de AA vs. celda de moneda, tiene que ver con el hecho de que los AA tienen tasas de descarga mucho más altas (los AA pueden entregar unos pocos amperios). Las celdas tipo moneda ( consulte una hoja de datos de muestra ) pueden entregar hasta unos pocos mA para pulsos cortos.

Gracias por la información. Me di cuenta de que estaba fuera de las especificaciones para esta prueba, pero los resultados parecían tener un patrón diferente a los valores que generalmente obtengo cuando bajo más los voltajes y fuerzo un apagón. Así que estaba tratando de averiguar si intenta cambiar y operar a 8 MHz antes de tirar la toalla.
Bien. Como Russel dice burlonamente en su publicación (que vinculé), al pasar las especificaciones, te estarás aventurando en un territorio desconocido. A medida que prueba los límites de MCU, puede parecer que las cosas funcionan, pero puede tener un comportamiento errático cuando menos lo espera. Por cierto, espero que no te hayas ofendido al vincular la respuesta de Russel, ya que es demasiado graciosa, pero ilustra bien mi punto.
Pero no, el ATmega no cambiará su reloj. Sería útil si lo hiciera, pero simplemente se rinde de formas inesperadas.
Gracias por el enlace. Sin ofender, en absoluto. Explicación concisa y clara. El enlace también fue bastante divertido e informativo. Solo desearía que stackexchange tuviera una función para marcar más de una solución como respuesta aceptable.
Sin sudar. Marque la respuesta que considere más útil para usted . Otros pueden votar diferente, pero aceptar la respuesta es tu elección :D
ATmega328P que se ejecuta en CR2032 tiene problemas con el código de sincronización/reposo ya que el voltaje se deprecia con el tiempo
RespuestasAquíPolítica de privacidad1y, 0v