Brick your STM32H735 in one easy step!

[MForb.1]

We're bringing up yet another custom board with the STM32H735 as the core processor. Built the first one, handed it to the software guy, and a few minutes later he says it's broken. Won't program, won't go to DFU mode, nothing. "You must have zapped it by accident!" Grumble.....get out the hot air gun and swap the part. At least it's a QFN100 and not some BGA package. Fixed, dropped it on his desk. Go to lunch.

Phone rings. "It's broken again. As soon as I downloaded code it died." Aaarrggghh! Back from lunch, steam off processor #2, install #3. This time, I'll make sure. Create a new IOC file, populate it with all the right pin settings, configure the peripherals, generate code in CubeMX, open project in CubeIDE. So far, so good. Add a couple lines to flash the debug blinkylight, hit download. Code downloads, processor goes away. No blinky. No nothin'. 

Vcore is at zero. On power-up, but NOT after hardware reset, there's a momentary blip on Vcore followed by a decay to ground. Somehow-or-other, the power supply setting was set for SMPS....and we're not using the SMPS. All of that is grounded. We had to go searching for this setting, and neither of us knew where to find it so it's a mystery how it got set that way. It should have been set to PWR_LDO_SUPPLY, which enables the internal LDO for Vcore and disables the SMPS. 

Once you've done this, there's no way back without finding a way to power Vcore externally, or scraping the part off the board and replacing it. In my case, I grabbed a LM117 adjustable regulator and tacked the adjust pin to ground and the supply to 3.3V. That sets the output to 1.25V, which I could then hotwire to the Vcore cap. Blinkylight! Hurray!

So.....if you're not using the SMPS, and you don't have an external source for Vcore, it's critical to make sure that the power supply is set to PWR_LDO_SUPPLY. You'll find this in CubeMX under the RCC settings. That is not where I would have expected to find it, and we had to fish around for a while before we tripped over it.

Seems to me that this should always default to LDO_SUPPLY, and there should be some kind of warning that brickage could happen if you don't have an external Vcore supply hooked up and any other option is selected. Fortunately I was careful pulling off the bricked parts, so I can re-use them and tack on my temporary hack to get them erased so they're back to working again. 

[Tesla DeLorean]

Recovery is typically via strapping BOOT0 High and cycling power a couple of times. Until you can connect the debugger and erase the broken code.

[waclawek.jan]

Interestingly, I've been told the same story with the same STM32 (in its non-crypto variant). I wonder if this has something to do that this is the only STM32 with SMPS not marked as such by the respective suffix. 

Yes, looking at you, ST.

JW

[LCE]

> Seems to me that this should always default to LDO_SUPPLY

I agree.

I had it his way around, programming the H735 on the eval board with the SMPS to use the LDO - which worked most of the time, and more important: it didn't kill the STM32, and it was easily re-programmable via ST-Link.

[LCE]

On the other hand:

the programmers are responsible for what is flashed into the chip, so never trust Cube or any other automatic code-generating tool.

CubeMX should maybe issue this warning after code generation: "Don't trust me!" :D

Check each source code line, and more important, especially before building your own custom board: RTFM!

Check datasheet, reference manual, "getting started" docs, and so on.

[SofLit · Accepted solution]

Hello @MForb.1 ,

To recover your "broken" chips, you can follow the steps described in this article.

Now regarding your proposal:

---

@MForb.1 wrote:

Seems to me that this should always default to LDO_SUPPLY, and there should be some kind of warning that brickage could happen if you don't have an external Vcore supply hooked up and any other option is selected. 

---

I'm escalating it internally and gat back to you as soon as I have a feedback. Internal ticket number for follow-up: 193895 

[MForb.1]

Perhaps you're right, but when you've used a tool for years with various different processors, and never had a problem, you tend to trust the results. We'd used this processor on one project previously and didn't run into this problem, so it's a bit puzzling why it worked then, and didn't work this time. I'm wondering if something changed in the latest update to CubeMX, such that the default power supply mode was different.

We've done dozens of STM32-based designs (maybe a hundred by now?) with parts from across the range from the F103 to the H735. We're very familiar with the datasheets and reference designs.

The BOOT0-driven-high trick is interesting....that should put the part in DFU mode, but I was unable to get its attention that way. I have a pushbutton on the board for that purpose, but no combination I found was able to get the LDO to run long enough to get it out of reset and connect with the debugger. I'll play around with that a bit more on the next board, where I will re-use one of my 'bricked' CPUs. 

[Tesla DeLorean]

The H7 has always been a pig in this regard, broke my beta H747I-DISCO pretty much immediately upon arrival as I built code for an NUCLEO-H743 w/LDO

The H7 treats a power cycle and a reset differently. It only reads option byte once at power-up, prevents reset based glitching attacks.ie the Reset is not as hard as in other devices.

[Tesla DeLorean]

Yeah, its super annoying, burned me on the first outing with H747I-DISCO beta, but there had to tack solder to an 0402 pad to get to BOOT0, recommended they add a switch/jumper on board.

But feel now this isn't uncharted waters, we've been discussing it for 5-6 years..