Is it possible to brick a 32F417?

[peter-h]

I wondered if e.g. programming all the SWD pins as outputs might prevent software loading.

My understanding is that if loading code with SWB this is not possible because the debugger resets the CPU, which floats all the pins, and then sends some sort of unique pattern to activate the SWD mode.

The exception to the above might be if you set some of the security fuses, which may prevent new code loading. But I am not doing that.

[bson]

When the processor is reset it immediately starts executing code.  The debugger then has to halt it, but there's a time window between the reset and halt that might allow your code to run, and debug interface gets disabled.  It depends a lot on the software and debugger, and whether the debugger is smart enough to do a fast halt immediately after reset.

You might be able to play with the BOOT pins to make the ST boot firmware sit and around and wait on a serial port or USB.  This would keep it from running your code and leave the debug pins intact.  The "fuses" are just flash bits that tell the ST boot firmware whether to enable/disable the debug interface prior to handing off control to your code.

[peter-h]

It appears that one way to break it is to misconfigure the clocks. For example if you set up the clock config to give you 168MHz with an 8MHz xtal, and then you load that code into a CPU which has a 25MHz xtal on it, the CPU will not do anything useful (at 525MHz) so the SWD interface won't run.

This appears to have actually been done.

The only ways out of it will be

- change the xtal to 8MHz or so
- set one of the BOOT0/1 pins to 1; IIRC this runs one of the boot blocks e.g. code loading via SPI, CAN or UART1 and then you can use the debugger again to load new code
- if you don't have a working program, erase the FLASH (using the debugger directly; I don't think ST Cube IDE has this option).

In my design I have a jumper called RECOVER which sets BOOT0=1. I could not remember why this was done Well, it can be read by software, so it isn't useless. But it may also be handy for enabling the debugger, where clocks or I/O have been misconfigured.

[Silenos]

Run the probe to connect in "under reset" mode?
I recall I have also crashed stms with bad pll settings and it was't a trouble in any way to overwrite the flash. No screwing with BOOT mode or w/e involved.

[ataradov]

It is impossible to brick those devices. The debugger may halt the core before any instructions are executed. You need to have reset connected on the debug interface, but that's it.

You can brick the device by using various security modes, of course.

[peter-h]

I thought that a secured CPU could always be reflashed?

I have no experience of current chips but that's how it always was with Atmel, Hitachi, and others, plus various PLDs which had "security fuses".

[ataradov]

Quote from the reference manual:

Memory read protection Level 2 is an irreversible operation. When Level 2 is activated, the level of protection cannot be decreased to Level 0 or Level 1.
Note:
The JTAG port is permanently disabled when Level 2 is active (acting as a JTAG fuse). As a consequence, boundary scan cannot be performed. STMicroelectronics is not able to perform analysis on defective parts on which the Level 2 protection has been set.

New Atmel/Microchip parts (like SAM L10/L11) also have the ability to permanently lock the device.

NXP has a similar mode, but they let you program a secret key that would unlock the device for failure analysis.

This is basically a feature that will be implemented in most devices going forward.

[amyk]

Of course, "permanent" is only relative - any of the various Chinese/Russian "MCU break" companies with FIB capability should be able to unlock it for a few k$...

[ataradov]

There are two different issues. Firmware disclosure is possible with those methods no matter the locking.

The permanent lock here is about not being able to reuse the device once locked, even for a custom, completely independent firmware. And this issue is addressed by replacing the device with a new one. No need to break anything just for that.

[AndyC_772]

I've (almost) bricked one of these by setting the BOR voltage to a level above the actual VCC used by the board.

It's unrecoverable without increasing VCC - particularly difficult if it's on a board with a fixed regulator and/or other parts that share the same supply, and all the more so if it's not in a package that you can easily 'just' remove and solder to a different PCB.

Be careful setting those option bytes, folks, especially if you have common software that runs on multiple hardware revisions that use different power supplies.

[ataradov]

Yes, this is a known way to soft lock the device. Some recent Atmel SAM parts disable the BOD for that reason when debugger is detected on reset.

But I had to recover the board in the past by applying higher voltage to get the BOD to release.

[DavidAlfa]

I've (almost) bricked one of these by setting the BOR voltage to a level above the actual VCC used by the board.

It's unrecoverable without increasing VCC - particularly difficult if it's on a board with a fixed regulator and/or other parts that share the same supply, and all the more so if it's not in a package that you can easily 'just' remove and solder to a different PCB.

Be careful setting those option bytes, folks, especially if you have common software that runs on multiple hardware revisions that use different power supplies.

Even if you connect under reset?