# STM32F091 VBat pin sinking a lot of mA's

I'm trying to set-up a STM32F091 with a battery connected straight into the VBAT pin. For the first couple times I turned on this vbat at 3V, it worked ok (no weird behavior). However, after trying to program the MCU via SWD, this VBat pin became a low impedance path to ground (around 150 Ohms) sinking 20mA. At first I thought this low impedance path was in my board, but then I removed the MCU and measured the resistance on the chip between pins VBAT and Ground, getting 159 ohms as a result. This problem manifested itself in two different chips and similar resistances were measured (150 and 250 ohms).

I'm inclined to believe this is a problem, since the VBat domain is supposed to power the RTC and back-up register, definitely not sinking 20mA @ 3V. I have not found any information on the device errata sheet and the data sheet says this pin draws uA's when powering the RTC domain.

The circuit is a straight connection between the battery and this pin. All others power pins are connected according to the datasheet. An interesting fact is that the ADC channel 18 (ADC_IN18) measures the voltage on VBat pin correctly.

Have anyone experienced this before? Am I missing something when using Vbat or is this a configuration issue?

Update: Problem found. See photos of PSU voltage wild excursions when turning off:

and turning on:

• If I measure the same pins on brand new chips(never programmed or used) I get around 600k ohms. Jun 9 '17 at 22:53
• Note to other readers here: Same question has been asked at the ST Community website (in case any updates there are also relevant here). Jun 9 '17 at 23:18
• I agree it seems you have damaged the MCU :-( (a) Can you share your schematic? (b) What external signals are connected to the MCU? (c) What's the history of the design e.g. is this a completely new design, or a development of an existing design, or ...? (d) Are you sure that the high current drain via VBAT started immediately after you programmed the MCU via SWD, or is that just when it was first noticed, but the current drain could have started earlier? (e) Have you considered buying the most similar STM32 Nucleo (with the F091 MCU), modify it to accept ext battery, and repeat your test? Jun 9 '17 at 23:26
• Hi, Sam. I've connected vbat on my workbench power supply(current limited) during tests. If the mcu was damaged, maybe this had something to do with it? That's the only connection to vbat in the circuit. Also, everything else works as expected, even the internal ADC channel on VBAT pin. A) B) C) It's a new design. D) Jun 9 '17 at 23:46
• A) MCU : i.imgur.com/8NP33tU.png ; High Level MCU connections i.imgur.com/jbDaHTm.png ; Battery NET i.imgur.com/51MXNyc.png B) The only signal off board is a USB connection where VBUS is powering the board during these tests while VBAT is on a power supply @ 3v. C) It's a new design. D) This happened on the previous revision of the board and this time I was specially watching for this behavior. So, the only event on the MCU besides powering it via USB + P.Supply(see C) ) was connecting to it and programming. e) Not yet.. Jun 10 '17 at 0:00

I don't see a definite "smoking gun" for your problem so far. Therefore this is some analysis of the partial schematic supplied, which may lead towards more tests which actually produce an answer. However, since this won't fit in (even several) comments, I'm adding it as an "answer":

• Just FYI, and not related to your problem, but the 100k pull-ups on I2C1 and I2C2 are very weak, and may be inadequate. Once you get the MCU working and can run some code, check the I2C waveforms for correct rise/fall times. I suspect you will need stronger pull-ups.

• One concern I had, was whether a signal voltage was being applied when VDD was off (i.e. with only VBAT active). Based on your updates, that doesn't seem to apply, but I recommend you review the full schematic, to see if that situation is possible.

• The localised issue around the VBAT pin (it seems to be localised since, as you said, other parts of the MCU work OK) suggests that VBAT is involved somehow. You mentioned VBAT being supplied from a battery, and later you said it is being supplied from a bench power supply (PSU). The latter is unusual, but I can't point to a reason why that won't work. I would use an oscilloscope to view the voltage on VBAT when you switch on that PSU, watching for overshoot or other similar issues.

• Another area to investigate, is the VDD supply. This hasn't been discussed much so far, and it might not seem relevant due to the visible symptom being with VBAT. However VDD will have been used to power the MCU during the attempted programming - and it is after this process, that you say the excessive VBAT current was found.

My thought process is that if VDD actually went briefly negative with respect to VSS during power-off for any reason, then the fact that there is another power source available (VBAT) could lead to unexpected issues in that area. Issues with VDD glitches to separate battery-backed RTC chips are well-known (a reverse-biased Schottky diode across VDD & VSS is the usual solution). I can't "join all the dots" to blame VDD behaviour with the data presented so far, but it's an area I definitely recommend investigating.

• In the current version of ST Reference Manual
RM0091: STM32F0x1/STM32F0x2/STM32F0x8 advanced ARM®-based 32-bit MCUs it says in section 5.1.3 (Battery backup domain) on pages 80 / 81:

tRSTTEMPO is shown in the STM32F091 Datasheet section 6.3.3 (Embedded reset and power control block characteristics) on page 55, as being between 1.5ms to 4.5ms, with a typical value of 2.5ms.

Therefore as I understand the above warning, if VDD rises within that time and VDD > VBAT + 0.6V then current injection to VBAT can occur.

I haven't see the VDD voltage mentioned in this topic yet, to know the result of the above formula. However adding the "low-drop" (e.g. Schottky) diode recommended by ST, seems like sensible mitigation to avoid potential problems caused by this behaviour inside the MCU.

• The lack of any pull-up or pull-down resistors (apart from on the two I2C buses mentioned earlier) visible on the partial schematics, would mean that until the MCU is programmed, almost all of the MCU GPIO pins will be floating digital inputs (confirmed in the Reference manual RM0091 section 8.3.1 General-purpose I/O (GPIO) ).

These pins are connected to other parts not shown in the partial schematic, but from the signal names, many are also inputs. This situation (inputs connected to inputs) could lead to undefined voltages on those pins, until code is running on the MCU and pins can be set to outputs where required, or internal pull-up or pull-down resistors can be activated, or until external components pull those inputs to valid logic level voltages. This is discussed here, and in lots of reference literature: Is it really a bad idea to leave an MCU input pin floating?

In general, best practice is to install pull-up or pull-down resistors on signals, to hold them at valid voltage levels while they are not being actively driven. One consequence of floating inputs can be excessive power consumption (due to the input transistors staying in the "threshold region") which is an interesting symptom in the context of this question.

• As you saw in my earlier suggestion, I suggested you could buy an STM32 Nucleo with the F091 MCU and modify it to add a separate VBAT supply (by default, VBAT is connected to VDD on that board). I found that someone has already done that on a slightly different Nucleo board, with some photos of the modification which may help you if you decide to go ahead, here: Battery Backup for RTC Clock & Registers on STM32 Nucleos

Notice the zero ohm resistor or link which must be removed in order to disconnect the VBAT pin from VDD, before you connect a battery to the VBAT pin!

• Assuming that you do get an ST Nucleo F091 then here are some suggestions. To make it a realistic test, you would first test the Nucleo board "as delivered", and make sure all is OK.

Then disconnect its on-board JTAG programmer (ST-Link), use your own JTAG programmer which you have been using so far, and re-test. Then use your own USB power supply and re-test etc. etc.

Gradually change the Nucleo board, step-by-step, to become more and more like your original board, testing with your "program the MCU using your JTAG programmer" test after each change (since that process seems to be what has damaged the MCUs on your board).

• If you "break" the Nucleo board, then it is something you are doing or something you are supplying (e.g. VDD), probably related to a recent change if you are following the process of making step-by-step changes as I suggested.

• If you don't break a Nucleo board, even when it is (as close as possible to) the same as your own "problem" boards, then either: The original problem is still something you are doing, but the different design of the Nucleo is mitigating the problem. Or the problem is in your board design, not what you are doing, and you need to look at the remaining differences (e.g. PCB layout, component choices, etc.) between your design and the Nucleo board for possible answers.

I hope that analysis is useful.

• On the possibility of damage from the PSU microchip.com/forums/m/tm.aspx?m=842010&p=1 Jun 11 '17 at 16:56
• Sscreenshots of my PSU when switching off(i.imgur.com/ocEkqxA.png) and on(i.imgur.com/wL9y1RR.png) across a 100k resistor. I suppose those high voltage peaks are a strong candidate for villains, right? Jun 12 '17 at 17:00
• It turns out my PSU was busting the VBat pin. When powered from a cleaner source, the problem was gone. Thanks. Jun 12 '17 at 20:28
• @MarcelNubi - I just started to look at those scope images, when I saw your next message that you've found the problem (good!) :-) So just to be clear: (a) You said it was the PSU that was damaging the VBat pin. Do you mean it was the USB PSU which you mentioned was powering your VDD (via USB Vbus), or was it the bench PSU which was powering VBat? (b) Those scope images don't seem to show a DC change between start & end, as we would expect for power-on or power-off, so I'm confused. Was the scope set to AC input coupling? (c) Related to (a) - were those scope images of Vbat or VDD? Thanks. Jun 12 '17 at 20:40
• @MarcelNubi - I did some tests with a bench PSU at work, and (as expected) couldn't reproduce similar spikes. The magnitude of the spikes in those scope images might be inaccurate, due to the possible effects of long scope ground leads etc., but even if the spikes were half as big, they would still be a problem. "time to purchase a better PSU" Or find/repair the fault in the existing one; or leave the PSU switched-on (assuming it doesn't produce the spikes while on) and add something like this on the output, to perform switching without spikes. Good luck! Jun 13 '17 at 17:02

There is no decoupling capacitor on VBAT

From AN3060

It is common for users to add a decoupling capacitor to any supply pin. However, in applications such as this, the leakage current in the capacitor may be as high as or higher than the backup current. That is, users could see the battery life appreciably shortened due to leakage through the capacitor. Furthermore, batteries have very good capacitor characteristics, so external capacitors are not needed.

We don't know how good "capacitor characteristics" does your PSU have, so it could be a problem.

Output current of PC13 is limited

From the Reference Manual RM0091

Due to the fact that the analog switch can transfer only a limited amount of current (3 mA), the use of GPIOs PC13 to PC15 in output mode is restricted: the speed has to be limited to 2 MHz with a maximum load of 30 pF and these IOs must not be used as a current source (e.g. to drive an LED).

If you are unsure, try relocating the PC13 VIR_EN signal to an unused I/O pin.

Operating without batteries

The Reference Manual also says

If no external battery is used in the application, it is recommended to connect VBAT externally to VDD with a 100 nF external ceramic decoupling capacitor.