Can your program, ever damage an MCU ??

[MathWizard]

I know you can set/burn fuses, and with external circuits wired up, you might overheat stuff, or apply the wrong voltage to a pin....


But with just power and GND, on modern MCU's, can you ever set something that internally conflicts, and can do bad, unpredictable  things or even damage the MCU ??

And for port protections, how many MCU's pins would have O/V voltage, or OVcurrent, or over temperature sensing ?

I'm sure some MCU's have that on certain pins, but how common is it ??

[Kim Christensen]

I guess you could let a bunch of IO pins float as inputs so they draw a lot of current.
Or have code that writes excessively to flash or eeprom and wears it out.
Otherwise, on a properly designed MCU, no real damage should happen from crap code.

I've never heard of MCU's with built in protection for their generic IO ports against O/V voltage, or OVcurrent, or over temperature sensing. (Beyond the simple diode clamps to Vdd/Gnd)
Some MCU's have pins that'll tolerate voltages a bit higher than Vdd, but not excessively so.

[brucehoult]

A program can do things such as reassign pins or change clock rates that make it impossible to connect with the usual debugger/programmer to upload a new program. There will be a window after power-on, but it can be too short to be usable. So the device is not physically damaged, but it is unusable.

Some chips, can recover from this by other means. e.g. AVRs have "high voltage programming". I don't know about others.

[ataradov]

Extremely unlucky code can change all sorts of factory calibration values. But I don't really see that happening on accident. Those programming interfaces are unlocked by wiring a very specific sequence into undocumented registers. And then the programming process itself is not trivial.

This is still technically not a physical damage, since device could be re-calibrated at the factory.

I don't think there is a way to cause true physical damage. 

[globoy]

I wonder if some complex multi-core SOCs could be damaged by a combination of setting too high of an internal voltage and too high of a clock rate (perhaps for too many cores) and overheating it.  But maybe they have built-in hardware throttles that would prevent an errant software configuration from setting up a condition that could damage the chip.

Or maybe there is a HW bug that could be exploited on some devices like on the recent Intel Core parts.

[dmendesf]

Intel just did that...

I wonder if some complex multi-core SOCs could be damaged by a combination of setting too high of an internal voltage and too high of a clock rate (perhaps for too many cores) and overheating it.  But maybe they have built-in hardware throttles that would prevent an errant software configuration from setting up a condition that could damage the chip.

Or maybe there is a HW bug that could be exploited on some devices like on the recent Intel Core parts.

[ataradov]

Intel case was a manufacturing defect. The CPUs were used at their advertised settings and still failed.

[globoy]

Intel case was a manufacturing defect. The CPUs were used at their advertised settings and still failed.

This article says it was a microcode bug: https://www.pcmag.com/news/intels-raptor-lake-bug-patch-is-here-how-much-does-it-affect-performance

And this article says there was a manufacturing defect but it wasn't the root cause of the big issues: https://www.tomshardware.com/pc-components/cpus/intel-announces-an-extra-two-years-of-warranty-for-its-chips-amid-crashing-and-instability-issues-longer-warranty-applies-to-13th-and-14th-gen-core-processors

"The company apologized for its slow response and released a statement reiterating its prior statement that Via Oxidation is not the root cause of the current instability issues. Intel says it first discovered the oxidation issue, which it characterizes as "minor," in 2022. The company says it instituted fixes and enhanced screening in early 2023 and removed all impacted chips from its supply chain by early 2024. However, it does concede that some chips with Via Oxidation defects could have still been on retail shelves as recently as early 2024."

But aside from wearing out flash (as has been mentioned) it does seem like it would be hard to do.

[ataradov]

This article says it was a microcode bug

It is either a shitty design or a manufacturing defect that got worked around by a microcode patch at the expense of performance. And presumably higher performance if why people bought them in a first place.

I could understand if the microcode did something that broke the chips, but did not affect performance otherwise. Then it is a just a bug that got fixed.

[dmendesf]

In their quest for the performance crown they managed to overvoltage their CPUs by fucking the microcode that controls voltages and clocks, so I think it somehow applies for this thread

BTW AMD just launched their 9000 series processors and performance was less than spectacular.  Their solution? Microcode to turn 65W processors into 105W processors. IThink I just saw this movie...

This article says it was a microcode bug

It is either a shitty design or a manufacturing defect that got worked around by a microcode patch at the expense of performance. And presumably higher performance if why people bought them in a first place.

I could understand if the microcode did something that broke the chips, but did not affect performance otherwise. Then it is a just a bug that got fixed.

[brucehoult]

This article says it was a microcode bug

It is either a shitty design or a manufacturing defect that got worked around by a microcode patch at the expense of performance. And presumably higher performance if why people bought them in a first place.

The power controller was giving the cores more voltage than was actually necessary to get the desired operating frequency, and causing damage. I believe that the fix, giving them the correct voltage, should result in the advertised performance with no damage. Unless of course you've already damaged your chip.

Apparently the laptop parts, such as the i9-13900HX in my Lenovo laptop, are the same chip but just run at lower voltage and wattage and frequency (supposedly 5.4 GHz, but I've never observed more than 5.3 on mine) that is fine.

[Jeroen3]

You can set the highest level of readout protection and erase the flash. 

[JPortici]

I did brick chips in the past
they all had ECC flash, the trick was to overwrite (while testing the firmware, or later by bugs) some key location that would be loaded at startup (for example, in dsPIC the configuration memory is loaded from flash right after VDD is stable, but if it was overwritten and hamming code doesn't match it will go straight to a hard fault, which if not programmed will lead to a reset which will load the configuration.... you get the drift). Some i manage to rescue by careful timing and entering programming mode before startup had initiated, some i didn't and went to the bin.

Chips with internal regulators, especially DCDC, i wonder if you can put them in such a state that they start to oscillate and destroy the chip

[hans]

Thought experiment; some crystals are using lower drive powers to resonate, like a few hundred uW. Their drivers are usually biased at some DC with a small sinusoidal voltage swing. They also typically aren't rated for high drive power

What if you would start driving these crystals between voltage rails? Would there be a resonance point at which these can break? In theory crystals have ultra high Q (hence the low drive power), so what if that could be used to destroy them.
In theory you could write a virus program that tunes the internal oscillator, switches them over so the devices remains (somewhat) operational, and then breaks the external oscillator. Or at least to such degree it becomes inaccurate for future operations after a reset.

[tszaboo]

Thought experiment; some crystals are using lower drive powers to resonate, like a few hundred uW. Their drivers are usually biased at some DC with a small sinusoidal voltage swing. They also typically aren't rated for high drive power

What if you would start driving these crystals between voltage rails? Would there be a resonance point at which these can break? In theory crystals have ultra high Q (hence the low drive power), so what if that could be used to destroy them.
In theory you could write a virus program that tunes the internal oscillator, switches them over so the devices remains (somewhat) operational, and then breaks the external oscillator. Or at least to such degree it becomes inaccurate for future operations after a reset.

If you can upload code to something, you can just write:
while(0);

[eutectique]

On NXP S32K, you can overstress and eventually damage flash if you write ones to already written location(s) -- that's what RefMan says.

Or think of an MCU powered by a PMIC, usually accessed via I2C. You can set a very wrong voltage or sequence which could cause physical damage. Not MCU feature, strictly speaking, but still falls under definition of "your program".

[MathWizard]

Ok so as long as I don't mess up the lock bits on some AVR chip, sloppy code should be fine, and should never hurt the chip. Yeah I never really heard people mention about damaging MCU's, but people do "brick" things like GPU's, when they upload the wrong code to it. I guess there's a bunch of chips in them that are locked off.


I know in older cars, you can drive in reverse for awhile, then put the car in forward drive and stress all the drivetrain and burn the tires a bit, on a car that otherwise can't burn tires. IDK if new cars still can do that or not.

But when you attach 2 high pins together and turn them on, and the voltage drops a lot, or attach the negative rail to the positive rail, that's not how modern computers do logic.

I guess shorting to high pins won't do much, it's just a jumper between two pins at almost the same voltage.

[radiolistener]

But with just power and GND, on modern MCU's, can you ever set something that internally conflicts, and can do bad, unpredictable  things or even damage the MCU ??

Some MCUs may have OTP fuses that control which features are enabled. If you write to these OTP fuses, you may lose access to certain MCU features. Some MCUs may also allow control of internal voltage regulators. Writing an incorrect value may lead to damage. You should also be cautious when configuring GPIO, when a pin is shorted to ground or the supply voltage may lead to excessive current and damage. In all other cases, there is no way to damage the MCU.

If MCU consume high power, there is also risk to get overheating, it also can damage it.

[MLXXXp]

Or have code that writes excessively to flash or eeprom and wears it out.

I think this would be one of the easiest ways to damage an MCU under the stipulated guidelines.

[westfw]

some complex multi-core SOCs could be damaged by a combination of setting too high of an internal voltage and too high of a clock rate

Microcontrollers as simple/cheap as the RPi rp2040 apparently let you adjust core voltage and clock rate far beyond "rated specifications."
It doesn't seem too unlikely that you could burn one out that way (I don't THINK that they have the built-in overtemp protections of more complex CPUs.)

[peter-h]

The Q is really: if a CPU contains no programmable features, can you mess it up?

Because if it has on-chip FLASH then obviously you can mess it up. Just load some duff code and disable the SWD/JTAG code loading On STM chips, RDP2 will do it nicely. Ordinarily I don't think you can disable code loading because SWD/JTAG starts with reset active (it's actually a debugger option, but normally one does use it) so no code can run.

Whether you can do damage by misprogramming an internal voltage regulator is interesting but not anything I've worked on.

[Phil1977]

What happens e.g. if you connect a medium sized cap to a push/pull output and switch it as fast as possible?

Are all MCUs protected against the resulting load or may a push/pull stage burn out? I think especially with programmable in-/outputs it´s not so uncommon to have caps connected there in real life applications.

[peter-h]

Localised heating for sure. The simplified circuits do not show any actual current limit components and certainly no temperature sensing.

[asmi]

If you grossly mismatch transmission line impedance and a high-speed driver, you can get some really impressive overshoot from reflections, but I'm not sure if it's ever going to be enough to damage driver because ESD diodes will supposedly prevent those overshoots from reaching the actual driver.

[nctnico]

Not an MCU but I have managed to destroy a Xilinx FPGA through software while developing in-circuit programming algorithms.