STM32H7 consumes excessive current in custom board - Page 1
Forum section: electronics / projects

author: RawCode
author_rank: Regular Contributor
timestamp: August 20, 2025, 04:18:07 pm
content: Hi everyone!I designed the board shown in the attached picture. It’s built around an STM32H745 microcontroller, along with crystal oscillators, a DAC, an EEPROM, and an NE555 that generates a reset signal when a button is pressed long enough.After assembling the board, I noticed that it draws an unusually high current (over 800 mA). The power supply goes into compliance and reduces the voltage, while the microcontroller itself becomes very hot to the touch. I noticed that the current rises with time to the compliance and over.To troubleshoot, I removed all external components (oscillators, DAC, EEPROM, transistors, and NE555), leaving only the microcontroller, but the excessive current consumption persists. I’ve checked carefully and I’m quite confident there are no shorts on the board.When I connect via ST-Link using STM32CubeProgrammer, the tool successfully detects and identifies the MCU. However, within a few seconds, the connection drops because the supply current rises above the compliance limit, causing the voltage to collapse.For comparison, I have a Nucleo board with the same MCU family, and it doesn’t exhibit this behavior: the current consumption is much lower, and the device remains cool.Does this increasing current consumption point to a short circuit I may have overlooked, a faulty microcontroller, or possibly a layout issue?Thank you in advance for your help.

author: SiliconWizard
author_rank: Super Contributor
timestamp: August 20, 2025, 06:09:58 pm
content: Yes, I can spot something that looks at least fishy: you connected VDDSMPS to GND.The datasheet says: "VDDSMPS must be kept at the same voltage level as VDD".You may have considered that not a problem if you were not going to use the internal SMPS, but nowhere does it state you can safely connect it to GND in that case.I suspect that it does create some internal short-circuit, possibly not directly but via an internal diode.At least that's the best I can think of for now. I don't know how easy it will be for you to test that withou respinning the board. Try to desolder the VDDSMPS pin, pull it up, and connect it to VDD via a small piece of wire, let me know how that goes. Hopefully nothing was destroyed internally.

author: RawCode
author_rank: Regular Contributor
timestamp: August 20, 2025, 07:30:05 pm
content: Hi SiliconWizard, thanks for the reply.According to the reference manual RM0399 (page 274-276) I chose the bypass configuration (config 6 in figure), which is the one that in theory I want. I checked the schematic and it seems that I connected everything correctly (according to the picture). Did I get something wrong?

author: SiliconWizard
author_rank: Super Contributor
timestamp: August 20, 2025, 09:04:35 pm
content: Ah, I had just checked out the datasheet, which doesn't mention this configuration, but the RM does indeed. So, it was a false lead.Apparently, you managed to connect to the MCU via SWD. Is the MCU completely blank?You said you removed all external components. There's a number of extra connections though on your schematic, where do they go? Just connectors?Do you directly supply the board with 3.3V?

author: RawCode
author_rank: Regular Contributor
timestamp: August 20, 2025, 09:28:10 pm
content: Yes, it seems that the MCU is completely blank: the memory is filled by 0xFFFFFFFF, as you can see in the attached picture.Yes, the extra connections goes to a connector. This board is a "processing" board that connects via pin headers to another board.During these tests the "processing" board was not connected to the other board, leaving the connections floating. The extra components I was referring to are those that are shown in the schematic. I also removed all capacitors, in case of a faulty one, but it did not change anything.Yes, I directly supply the board with 3.3V via a Siglent power supply.

author: Dan N
author_rank: Contributor
timestamp: August 20, 2025, 09:33:55 pm
content: Quote from: RawCode on August 20, 2025, 09:28:10 pmThat's your problem. The maximum direct core voltage for that configuration is 1.4V (datasheet Table 23).

author: SiliconWizard
author_rank: Super Contributor
timestamp: August 20, 2025, 09:44:57 pm
content: Quote from: Dan N on August 20, 2025, 09:33:55 pmWell, we need to be more specific, but that helped me spot the issue. The problem is that the OP connected the VCAP pins to the +3.3V rail, which is wrong! VCAP is the output of the internal LDO and must only be bypassed with capacitors, but otherwise not connected to anything else.

author: Dan N
author_rank: Contributor
timestamp: August 20, 2025, 09:48:38 pm
content: Quote from: SiliconWizard on August 20, 2025, 09:44:57 pmHe's using it in bypass mode, the LDO is disabled and VCAP is connected directly to the internal core as shown in the picture above.

author: langwadt
author_rank: Super Contributor
timestamp: August 20, 2025, 09:51:27 pm
content: Quote from: SiliconWizard on August 20, 2025, 09:44:57 pmexcept in configuration 2,5,6

author: SiliconWizard
author_rank: Super Contributor
timestamp: August 20, 2025, 10:38:53 pm
content: Yes, not with 3.3V on VCAP though. In the OP's case, that made no sense. The internal LDO is perfectly fine and its voltage output can be internally programmed depending on the system clock.A reason to bypass it would be if using a more efficient external regulator, but not at 3.3V.Also note that to use the bypass mode, there are constraints regarding the voltage you apply to VCAP, it must be higher than 1.1V until you disable the LDO by software, so if you implement an external programmable core voltage rail, that's something to care about. Otherwise, you can use a fixed value that will work for the system clock you'll be using (1.4V being the maximum). But that's not that efficient if not programmable - the internal LDO is programmable and will allow reducing VCORE for lower frequencies, allowing to significantly decrease power draw at lower frequencies/sleep mode.Again in the OP's case, his best bet is just to cut off the trace from the 3.3V rail to all VCAP pins, if it's doable on his PCB.This chip also has an internal SMPS, but the OP decided not to use it. One reason to use an external core voltage would be for very specific use cases, or if you want to limit the MCU's temperature at the higher frequencies: at the max 480 MHz, these STM32H7 get pretty warm when running on the internal LDO, and a significant part of the temperature rise is due to the LDO itself. I have a dev board with a STM32H7 and at 480 MHz on internal LDO, the die gets over 50°C @ 25°C ambiant. Nothing that will reduce its lifespan, but could be concerning if operating in hot environments and/or in a very small enclosure with no ventilation.

author: Psi
author_rank: Super Contributor
timestamp: August 20, 2025, 11:05:14 pm
content: Have you confirmed it does this again with a new good MCU, maybe you just accidentally did something that damaged the MCU without realizing it. Some wires touched, probe slipped and shorted two pins etc..As soon as a MCU gets hot from higher than normal current draw there's a real chance something inside is damaged, even if it still seems to work and program fine. They don't always fail to 100% dead. I've had some weird MCU failures over the years. Caused by me doing something stupid, but that manifested in odd ways.Also check through the datasheet and just confirm your SCH symbol has all the correct pin numbering to match the datasheet for your exact package.The way STM32 does pin number listing is prone to errors as its a big table with all pin number for all packages. So it's easy to get mixed up when making a SCH symbol and read the wrong line. Which can obviously cause a pin to go to the wrong place and be non-obvious when looking at the schematic.I would have already checked it for you if it was 32pin, but 144pins is just too many and I have not had my coffee yet.

author: RawCode
author_rank: Regular Contributor
timestamp: August 21, 2025, 12:46:31 pm
content: Thank you very much for spotting the error!Yeah, VCAP should be tied to the 1.2V rail, not 3.3V.Time to cut some traces