Excessive backup battery current draw on board power down. Better way to fix it?

[Cody1]

I have a board using an STM32F407VGT6 that draws excessive current from the backup battery for the RTC when board power is bleeding down. The board is powered by 24VDC and bucked to +5V with an LDO used to generate the +3.3V power for the STM32. A super capacitor and ideal diode are used on a +5V line to keep it high when +24V is disconnected from the board. This allows a SOM that is using the +5V line to run some final operations before complete board shutdown. What I found is that during the bleed down of the +5V rail, the backup battery will spike to +1mA current draw and slowly decrease as the +5V rail completely bleeds off. It takes several minutes for the +5V line to completely bleed. The 3.3V line is not being held high during the +5V bleed off; it actually seems to clamp at around 0.8V and stay there until the +5V line has bled all the while drawing 100's of uA of current from the battery backup.

I did manage to remedy the problem (for the most part) by switching the supply voltage for the 3.0V ADC reference voltage from 5V to 3.3V and adding a switch on the front side of the LDO that opens the 5V supply to the 3.3V LDO when board power is disconnected. Only when I did both of these did the current draw from the battery backup drastically decrease during power. The battery backup current now spikes to only about 2.6uA and takes 20s to reach steady state of <1uA.

That is a lot of information, but my main question is whether there is a better solution to remedy this problem? The issue does appear to be internal to the STM32 and how it manages power down with respect to VDD voltage.

[waclawek.jan]

The VBAT/VDD switch is governed by the RESET circuit, so things to check are the PDN_ON and VDDA/VSSA pins (I mean, check physically, for bad solder joints, shorts, design errors) and the brownout settings.

JW

[Cody1]

JW,

I am using the LQFP100 package which does not have a PDN_ON pin. There is a reset monitor for the reset pin that is working almost immediately after power power is lost. The VDDA pin could have been a problem which I addressed with the switch between +5V and the 3.3V regulator (VDDA is powered from 3.3V). This issue is present on multiple board (>5) so it definable is a board design problem or something wrong with the STM32 operation or settings.

I wonder if this is an issue specific to the LQFP100 and LQFP64 packages? These are the only packages that do not have a PDR_ON pin. There is also this note from the datasheet that is a bit intriguing.

"When PDR_ON pin is not connected to VDD (internal reset OFF), the VBAT functionality is no more available and VBAT pin should be connected to VDD."

Again, I did mangage to find a fix for the problem; however, I feel that there should definatley be a way to alleviate this issue with software unless this is a problem specific to the LQFP100 package without the PDR_ON pin.

[waclawek.jan]

PDR_ON is internally tied to whatever level is needed to make rest operational on the 100/64-pin devices, you don't need to be worried about it.

The problem IMO lies in the unusually complex power supply mechanism you are using -I didn't understand your description above, a schematic or sketch, and maybe waveforms, would help.

IMO, the VBAT to VDD switch is controlled by the internal reset/voltage detector, not by the NRST pin. I may be wrong.

Please re-check the VDDA/VSS/VSSA connections as I wrote above, by directly measuring on the pins.

If you have a related Nucleo, you can try to experiment with VBAT there.

JW

[Cody1]

JW,

Thank you for your response. I have attached a block diagram that explains the power supply scheme in greater detail. Maybe that will shed some light on things.

I am going to try and capture some long measurements of the power pins again for reference. However, I do remember from previous testing that the VDD pin seemed to be latched to 0.7V while the 5VDC rail (powered by the super capacitor) drained. Again, the second block diagram in the attached image essentially fixes the excessive battery draw issue; however, I feel there should be a better solution.

Thanks,

Cody

[Cody1]

Also, There is a reset manager tied to the microcontroller that forces it into reset when the 3.3V line is below 2.93V. I forgot to add that in the block diagram.