STM32F091 pin VBat hundiendo una gran cantidad de mA

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:

imagen de alcance de apagado

y encendiendo:

imagen de alcance de encendido

Si mido los mismos pines en chips nuevos (nunca programados ni usados) obtengo alrededor de 600k ohmios.
Nota para otros lectores aquí: se hizo la misma pregunta en el sitio web de la comunidad ST (en caso de que haya actualizaciones también relevantes aquí).
Estoy de acuerdo, parece que has dañado la MCU :-( (a) ¿Puedes compartir tu esquema? (b) ¿Qué señales externas están conectadas a la MCU? (c) ¿Cuál es la historia del diseño, por ejemplo, es un diseño completamente nuevo? o un desarrollo de un diseño existente, o...? (d) ¿Está seguro de que el drenaje de alta corriente a través de VBAT comenzó inmediatamente después de programar la MCU a través de SWD, o es justo cuando se notó por primera vez, pero el drenaje de corriente ¿Podría haber comenzado antes? (e) ¿Ha considerado comprar el Núcleo STM32 más similar (con la MCU F091), modificarlo para aceptar la batería externa y repetir su prueba?
Hola Sam. Conecté vbat en la fuente de alimentación de mi banco de trabajo (corriente limitada) durante las pruebas. Si el mcu estaba dañado, ¿quizás esto tuvo algo que ver con eso? Esa es la única conexión a vbat en el circuito. Además, todo lo demás funciona como se esperaba, incluso el canal ADC interno en el pin VBAT. A) B) C) Es un nuevo diseño. D)
A) UCM: i.imgur.com/8NP33tU.png ; Conexiones MCU de alto nivel i.imgur.com/jbDaHTm.png ; Battery NET i.imgur.com/51MXNyc.png B) La única señal fuera de la placa es una conexión USB donde VBUS está alimentando la placa durante estas pruebas mientras VBAT está en una fuente de alimentación @ 3v. C) Es un nuevo diseño. D) Esto sucedió en la revisión anterior del tablero y esta vez estaba especialmente atento a este comportamiento. Entonces, el único evento en la MCU además de alimentarla a través de USB + P.Supply (ver C) fue conectarse y programar. e) Todavía no..
Gracias por esa información, Marcel. Mi análisis de los datos hasta ahora no cabe en (ni siquiera en varios) comentarios, por lo que lo publiqué como respuesta, aunque es solo un paso hacia eso.
Gracias, Sam. Actualmente estoy de viaje, ¡lo investigaré lo antes posible!

Respuestas (2)

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:

    Extracto del manual de referencia ST RM0091 - Suministro VBAT durante el encendido

    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.

Sobre la posibilidad de daño del PSU microchip.com/forums/m/tm.aspx?m=842010&p=1
Capturas de pantalla de mi PSU cuando se apaga ( i.imgur.com/ocEkqxA.png ) y se enciende ( i.imgur.com/wL9y1RR.png ) a través de una resistencia de 100k. Supongo que esos picos de alto voltaje son un fuerte candidato para villanos, ¿verdad?
Resulta que mi fuente de alimentación estaba rompiendo el pin VBat. Cuando se alimenta desde una fuente más limpia, el problema desaparece. Gracias.
@MarcelNubi: comencé a mirar esas imágenes de alcance, cuando vi su siguiente mensaje que había encontrado el problema (¡bien!) :-) Entonces, para ser claro: (a) Dijiste que era la fuente de alimentación que era dañar el pin VBat. ¿Quiere decir que fue la fuente de alimentación USB que mencionó que estaba alimentando su VDD (a través de USB Vbus), o fue la fuente de alimentación de banco que estaba alimentando VBat? (b) Esas imágenes de alcance no parecen mostrar un cambio de CC entre el inicio y el final, como esperaríamos para el encendido o el apagado, por lo que estoy confundido. ¿Se configuró el osciloscopio en acoplamiento de entrada de CA? (c) Relacionado con (a): ¿eran esas imágenes de alcance de Vbat o VDD? Gracias.
Supongo que las respuestas son (a) es la PSU para Vbat; (b) el alcance se configuró en CC, pero estos picos ocurrieron cuando el voltaje de salida de la PSU ya estaba en estado estable, es decir, no mientras el voltaje estaba cambiando realmente como se esperaba, durante el encendido/apagado; (c) las imágenes eran VBat. Si interpreto las imágenes correctamente, hay un pico de -6 V (1,1 divisiones a 5 V/div) durante el encendido y picos de más de +/- 20 V (más de +/- 2 divisiones a 10 V/div) durante el apagado . ¡Muy atemorizante! Me alegro de que mi sugerencia de verificar VBat haya sido útil. ¡Buena suerte!
a) Sí, PSU para VBat. Cuando se alimentaba de una fuente limpia, esos picos desaparecieron. b) Estaba configurado para DC pero la ventana de tiempo era muy corta (50 us). Esos picos ocurrieron antes de que la energía subiera a 3V o bajara a 0V. Realmente aterrador... es hora de comprar una fuente de alimentación mejor, ¿verdad?
@MarcelNubi: hice algunas pruebas con una fuente de alimentación de banco en el trabajo y (como era de esperar) no pude reproducir picos similares. La magnitud de los picos en esas imágenes de alcance puede ser inexacta, debido a los posibles efectos de los cables de tierra de alcance largo, etc., pero incluso si los picos fueran la mitad de grandes, seguirían siendo un problema. "es hora de comprar una fuente de alimentación mejor" O encontrar/reparar la falla en la existente; o deje la fuente de alimentación encendida (suponiendo que no produzca los picos mientras está encendida) y agregue algo como esto en la salida, para realizar la conmutación sin picos. ¡Buena suerte!

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_ENseñ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.