Estoy tratando de configurar un STM32F091 con una batería conectada directamente al pin VBAT. Las primeras veces que encendí este vbat a 3V, funcionó bien (sin comportamiento extraño). Sin embargo, después de intentar programar la MCU a través de SWD, este pin VBat se convirtió en un camino de baja impedancia a tierra (alrededor de 150 ohmios) hundiendo 20 mA. Al principio pensé que esta ruta de baja impedancia estaba en mi placa, pero luego quité la MCU y medí la resistencia en el chip entre los pines VBAT y Tierra, obteniendo como resultado 159 ohmios. Este problema se manifestó en dos chips diferentes y se midieron resistencias similares (150 y 250 ohmios).
Me inclino a creer que esto es un problema, ya que se supone que el dominio VBat alimenta el RTC y el registro de respaldo, definitivamente no hundiendo 20mA @ 3V. No he encontrado ninguna información en la hoja de errata del dispositivo y la hoja de datos dice que este pin atrae uA cuando se alimenta el dominio RTC.
El circuito es una conexión directa entre la batería y este pin. Todos los demás pines de alimentación están conectados de acuerdo con la hoja de datos. Un hecho interesante es que el canal ADC 18 (ADC_IN18) mide el voltaje en el pin VBat correctamente.
¿Alguien ha experimentado esto antes? ¿Me estoy perdiendo algo cuando uso Vbat o es un problema de configuración?
Actualización: Problema encontrado. Vea fotos de excursiones salvajes de voltaje de PSU al apagar:
y encendiendo:
No veo una "pistola humeante" definitiva para su problema hasta ahora. Por lo tanto, este es un análisis del esquema parcial proporcionado, que puede conducir a más pruebas que realmente produzcan una respuesta. Sin embargo, dado que esto no encajará en (ni siquiera en varios) comentarios, lo agregaré como una "respuesta":
Solo para su información, y no está relacionado con su problema, pero los pull-ups de 100k en I2C1 e I2C2 son muy débiles y pueden ser inadecuados. Una vez que haga que la MCU funcione y pueda ejecutar algún código, verifique las formas de onda I2C para ver los tiempos correctos de subida/bajada. Sospecho que necesitarás dominadas más fuertes.
Una preocupación que tenía era si se estaba aplicando un voltaje de señal cuando VDD estaba apagado (es decir, con solo VBAT activo). Según sus actualizaciones, eso no parece aplicarse, pero le recomiendo que revise el esquema completo para ver si esa situación es posible.
El problema localizado alrededor del pin VBAT (parece estar localizado ya que, como dijiste, otras partes de la MCU funcionan bien) sugiere que VBAT está involucrado de alguna manera . Mencionó que VBAT se alimenta de una batería, y luego dijo que se alimenta de una fuente de alimentación de banco (PSU). Esto último es inusual, pero no puedo señalar una razón por la que no funcione. Usaría un osciloscopio para ver el voltaje en VBAT cuando enciende esa fuente de alimentación, observando si hay un exceso u otros problemas similares.
Otra área a investigar es el suministro de VDD. Esto no se ha discutido mucho hasta ahora, y puede que no parezca relevante debido a que el síntoma visible es con VBAT. Sin embargo, se habrá utilizado VDD para alimentar la MCU durante el intento de programación, y es después de este proceso, que dice que se encontró una corriente VBAT excesiva.
Mi proceso de pensamiento es que si VDD en realidad fue brevemente negativo con respecto a VSS durante el apagado por cualquier motivo, entonces el hecho de que haya otra fuente de alimentación disponible (VBAT) podría generar problemas inesperados en esa área. Los problemas con las fallas de VDD para separar los chips RTC respaldados por batería son bien conocidos (la solución habitual es un diodo Schottky con polarización inversa en VDD y VSS). No puedo "unir todos los puntos" para culpar al comportamiento de VDD con los datos presentados hasta ahora, pero es un área que definitivamente recomiendo investigar.
En la versión actual del Manual de referencia de ST
RM0091: STM32F0x1/STM32F0x2/STM32F0x8 MCU avanzados de 32 bits basados en ARM®, dice en la sección 5.1.3 (Dominio de respaldo de batería) en las páginas 80/81:
t RSTTEMPO se muestra en la hoja de datos STM32F091, sección 6.3.3 (Características del bloque de control de energía y restablecimiento integrado) en la página 55, entre 1,5 ms y 4,5 ms, con un valor típico de 2,5 ms.
Por lo tanto, según entiendo la advertencia anterior, si VDD aumenta dentro de ese tiempo y VDD> VBAT + 0.6V, entonces puede ocurrir una inyección de corriente a VBAT.
Todavía no he visto el voltaje VDD mencionado en este tema, para saber el resultado de la fórmula anterior. Sin embargo, agregar el diodo de "caída baja" (por ejemplo, Schottky) recomendado por ST parece una mitigación sensata para evitar posibles problemas causados por este comportamiento dentro de la MCU.
La falta de resistencias pull-up o pull-down (aparte de los dos buses I2C mencionados anteriormente) visibles en los esquemas parciales significaría que hasta que se programe la MCU, casi todos los pines GPIO de la MCU serán entradas digitales flotantes (confirmado en el Manual de referencia RM0091, sección 8.3.1 E/S de propósito general (GPIO)).
Estos pines están conectados a otras partes que no se muestran en el esquema parcial, pero por los nombres de las señales, muchos también son entradas. Esta situación (entradas conectadas a entradas) podría generar voltajes indefinidos en esos pines, hasta que el código se ejecute en la MCU y los pines se puedan configurar en salidas donde sea necesario, o se puedan activar resistencias pull-up o pull-down internas, o hasta que los componentes externos extraen esas entradas a voltajes de nivel lógico válidos. Esto se discute aquí y en mucha literatura de referencia: ¿Es realmente una mala idea dejar flotando un pin de entrada de MCU?
En general, la mejor práctica es instalar resistencias pull-up o pull-down en las señales, para mantenerlas en niveles de voltaje válidos mientras no se activan activamente. Una consecuencia de las entradas flotantes puede ser un consumo de energía excesivo (debido a que los transistores de entrada permanecen en la "región de umbral"), lo cual es un síntoma interesante en el contexto de esta pregunta.
Como vio en mi sugerencia anterior, sugerí que podría comprar un STM32 Nucleo con el MCU F091 y modificarlo para agregar un suministro VBAT separado (de forma predeterminada, VBAT está conectado a VDD en esa placa). Descubrí que alguien ya lo ha hecho en una placa Nucleo ligeramente diferente, con algunas fotos de la modificación que pueden ayudarlo si decide seguir adelante, aquí: Respaldo de batería para reloj RTC y registros en STM32 Nucleos
¡Observe la resistencia o enlace de cero ohmios que se debe quitar para desconectar el pin VBAT del VDD, antes de conectar una batería al pin VBAT!
Suponiendo que obtenga un ST Nucleo F091, aquí hay algunas sugerencias. Para que sea una prueba realista, primero probaría la placa Nucleo "tal como se entregó" y se aseguraría de que todo esté bien.
Luego desconecte su programador JTAG incorporado (ST-Link), use su propio programador JTAG que ha estado usando hasta ahora y vuelva a probar. Luego use su propia fuente de alimentación USB y vuelva a probar, etc., etc.
Cambie gradualmente la placa Nucleo, paso a paso, para que se parezca cada vez más a su placa original, probando con su prueba "programe la MCU usando su programador JTAG" después de cada cambio (ya que ese proceso parece ser lo que ha dañado las MCU ) . en su tablero).
Si "rompe" la placa Nucleo, entonces es algo que está haciendo o algo que está suministrando (por ejemplo, VDD), probablemente relacionado con un cambio reciente si está siguiendo el proceso de realizar cambios paso a paso como sugerí.
Si no rompe un tablero Nucleo, incluso cuando es (lo más parecido posible) al mismo que sus propios tableros "problemáticos", entonces: El problema original sigue siendo algo que usted está haciendo, pero el diseño diferente del Núcleo está mitigando el problema. O el problema está en el diseño de su placa , no en lo que está haciendo , y necesita ver las diferencias restantes (por ejemplo, diseño de PCB, opciones de componentes, etc.) entre su diseño y la placa Nucleo para encontrar posibles respuestas.
Espero que el análisis sea de utilidad.
No hay condensador de desacoplamiento en V BAT
Desde AN3060
Es común que los usuarios agreguen un capacitor de desacoplamiento a cualquier pin de suministro. Sin embargo, en aplicaciones como esta, la corriente de fuga en el capacitor puede ser tan alta o mayor que la corriente de respaldo. Es decir, los usuarios podrían ver que la duración de la batería se acorta considerablemente debido a la fuga a través del condensador. Además, las baterías tienen muy buenas características de condensadores, por lo que no se necesitan condensadores externos.
No sabemos qué tan buenas "características de condensador" tiene su PSU, por lo que podría ser un problema.
La corriente de salida de PC13 es limitada
Del Manual de referencia RM0091
Debido al hecho de que el conmutador analógico puede transferir solo una cantidad limitada de corriente (3 mA), el uso de GPIO PC13 a PC15 en modo de salida está restringido: la velocidad debe limitarse a 2 MHz con una carga máxima de 30 pF y estos IO no deben usarse como fuente de corriente (por ejemplo, para controlar un LED).
Si no está seguro, intente reubicar la PC13
VIR_EN
señal en un pin de E/S no utilizado.
Funcionamiento sin pilas
El Manual de Referencia también dice
Si no se utiliza una batería externa en la aplicación, se recomienda conectar V BAT externamente a V DD con un capacitor de desacoplamiento cerámico externo de 100 nF.
MarcelNubi
Sam Gibson
Sam Gibson
MarcelNubi
MarcelNubi
Sam Gibson
MarcelNubi