STM32L433CCT6: VBAT current anomaly

[Peter Mather]

I'm still having problems with VBAT current consumption. I've loaded my firmware and the processor behaves correctly in all other respects. I removed all components from the processor to insure that there are no sneak paths for parasitic current draw. All that is connected to it is the 32Khz crystal and its capacitors and a high quality meter capable of measuring tenths of micro-amperes which is in series with the coin cell and the VBAT pin. The circuit board has been meticulously cleaned.

I connect a coin cell to VBAT and apply 3.3 volts to Vdd. The processor works fine and the 32Khz oscillator is running. VBAT current is zero. 

I remove the 3.3 volts and VBAT current is 0.3 micro-amperes which is exactly as per the datasheet. The oscillator is running.

I reapply 3.3 volts and then remove it. VBAT current goes up to 60 micro-amperes. Subsequent cycling of Vdd does not improve things. Neither does resetting by momentarily grounding NRST. The only way to get VBAT back to 0.3 micro-amperes is to remove both VBAT and Vdd and reapply them. 

Any help you can give would be appreciated. 

[waclawek.jan]

Try with a minimal program which does nothing just goes into infinite loop after reset.

Still increased VBAT current?

JW

[PTana]

We are experiencing a very similar issue with our MCU (STM32L475VGT6). We are using a 22uF ceramic cap across VBAT pin to GND. The intended application is to keep the RTC with backup registers running when our power source is disconnected for less than 10seconds. The MCU datasheet suggests that we should be getting about 1minute of time running in VBAT mode (with the stated 494nA max current in VBAT mode). However, VBAT voltage is dropping below the 1.45V limit in less than 1 second.

We also stripped down our code to minimize all functionality. This same issue has been consistently observed on all 3 prototypes tested. We tried all combinations of relevant register settings, as discussed in the following forum with apparently similar issues: https://electronics.stackexchange.com/questions/310059/stm32f091-vbat-pin-sinking-a-lot-of-mas

We have tried using both LSE and LSI.

We have also tried charging the 22uF cap across VBAT via a Schottky diode connected to VCC.

We get the expected behavior for our design when tested with the Nucleo board (Nucleo-L496ZG), but we haven't been able to replicate this same behavior with our MCU (STM32L475VGT6).

[PTana]

Peter Mather, have you had any success it correcting or better understanding the VBAT functionality?

[waclawek.jan]

And if you charge the same (I mean, physically the same) ceramic cap alone (i.e. disconnected from the mcu) and then leave it to discharge, what's the observation? (i.e. isn't the capacitor itself leaky)

Do you have all ground pins and all power pins connected properly, especially the analog ones?

Did you charge the capacitor long enough (at least as long as you expect to run from it, the longer the better)?

> We have tried using both LSE and LSI.

LSI does not run from VCAP.

JW

PS. Note, that in the case you gave link to, the problem was a power supply with excessive noise when powering down.

[PTana]

Hi JW,

Thanks so much for taking the time to help!

We've measured a fall time of many minutes (~15min) when charging and then discharging the cap by itself (i.e., not connected to the MCU); this caused us to conclude that leakage through the capacitor is not a significant factor (i.e., resulting in a fall time of <1sec when connected to the VBAT pin of the MCU).

Here's a screen shot of all power and ground connections for the MCU:

We've tested this first with the Schottky diode connected between VCC and VBAT (as shown in the schematic) and then without the diode.

The cap has been left to charge for various durations (certainly >10sec prior to most tests). We've measured the charging and discharging curves using an oscilloscope.

Here's the link I meant to provide above describing similar issues with the apparent fix of setting the PWREN bit: https://community.st.com/s/question/0D50X00009XkWckSAF/stm32-l4-vbat-internal-battery-charging

We tried using the LSI and LSE after we felt that we exhausted our other options. The intent was to disable the LSE, which could've contributed to a shorter fall time during VBAT mode (but we didn't observe any difference in the fall time).

Thanks again for you help!

[PTana]

The root cause of the short duration has been proven to be due to unexpectedly low input resistance of our logic analyzer. I was previously using the logic analyzer functionality of our scope to facilitate use of nanoprobes on our prototype PCBA. With the Nucleo board I was using an analog probe of the scope since I was able to easily grab onto the through-hole capacitor I added across the VBAT pin; this explains why we were measuring acceptable fall times with the Nucleo, but not with our prototype. We are now measuring fall times which align with our calculations. Thanks for your help JW!