STM32F091 VBat pin sinking a lot of mA's

Question

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:

Answer 1

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:

  

  t_RSTTEMPO 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.

Answer 2

There is no decoupling capacitor on V_BAT

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 V_BAT externally to V_DD with a 100 nF external ceramic decoupling capacitor.