是否有可能通过软件破坏微控制器？

假设：

• 未连接任何外部电路（编程电路除外，我们认为这是正确的）。
• uC并非故障。
• 摧毁，我的意思是释放死亡的蓝色烟雾，而不是在软件中积压。
• 这是一个“正常”的uC。没有一些非常奇怪的百万分之一非常特定用途的设备。

有没有人看过类似的事情发生？这怎么可能？

背景：

在我协助下举行的一次聚会的发言人中说，这样做是可能的，甚至没有那么困难，其他一些人也同意他的想法。我从未见过这种情况发生，当我问他们怎么可能时，我没有得到真正的答案。我现在真的很好奇，很想得到一些反馈。

当然，可以使用HCF指令！

就是说，我说，除了电源等之外，没有任何外部电路是不可能的。

甚至包括一些非故意的错误连接也可能无法解决问题：如果将所有gpios绑在电源轨上，则将它们设置为输出（连接到相反的电源轨）会消耗很多功率。gpio引脚可能具有短路保护，因此不会产生有害影响。

在我看来，设计一个可以随意破坏芯片的外部电路也不是一件容易的事。首先想到的是需要一个高压电源，一个nmos和一个电阻：

^{模拟该电路 –使用CircuitLab创建的原理图，} 其中：

• 是微型电源的常用电源，大约3v3至5V或任何需要的电源$V_{CC}$
• HV是一种电源，其电压远高于微型设备的绝对最大额定值
• D1在那里可以保护您宝贵的3V3电压源
• 当微型麦克风未将其接地时，R1将mosfet栅极拉高
• M1被指定为杀手

操作很简单：如果Micro释放GPIOx M1打开，则Vcc上升，并且芯片着火。请注意，这是一个糟糕的设置，例如，在您特别确定GPIOx牢固接地后，必须打开HV 。某些晶体管可能不喜欢某些-5V Vgs，依此类推……但是您了解了。

免责声明：supercat首先在评论中表示。

实际上，不可能物理破坏大多数MCU，但可以将其磨损到足以使设备开始无法使用的程度。我在TI的MSP430方面拥有丰富的经验，因此请按以下步骤进行：

这些MCU允许随时重新编程整个闪存。不仅有可能通过重写闪存达数百万次来使闪存磨损直到出现故障，而且如果编程生成器配置不正确，片上闪存编程生成器也可能导致低端处理器出现故障。这些是编程允许的频率允许范围。当超出该范围（较慢）时，编程时间可能会变得过长，并导致闪存失效。仅几百个周期之后，就有可能“烧毁”闪存单元而导致永久性故障。

另外，某些型号允许超频内核，以便通过增加内部电压使其达到更高的速度。MCU使用1.8-3.6V电源供电，但内核本身设计为以1.8V运行。如果您在切换所有I / O，激活所有外设并在封闭的小机箱中以惊人的40MHz频率运行（大型机型通常为最大25MHz）时对3.6V电源轨的内核进行了超频，那么您可能最终会油炸核心因为过热。实际上，有些人说他们达到了这些频率（通常DCO之前就失败了，并且保存了芯片，但是...

去尝试一下？

根据stackexchange-“让MCU输入引脚悬空真的是一个坏主意吗？”

它描述了芯片开路引脚可能损坏芯片的几种情况。编辑：一个示例Spansion模拟和微控制器产品说：

4.1端口输入/未使用的数字I / O引脚
强烈建议在将数字I / O引脚切换为输入时，不要断开它们的连接。在这种情况下，这些引脚可以进入所谓的浮动状态。这会导致高ICC电流，这不利于低功耗模式。MCU的损坏也可能发生。

这个问题的条件是引脚完全开路。

所以，我们的任务是开车，从5月份到会损坏引脚。我认为这已经超出了“砖化”的范围。

该答案中确定的一种机制是将输入引脚驱动到中值电压，其中两个互补晶体管都“导通”。在该模式下运行，引脚接口可能变热或发生故障。

输入引脚具有很高的阻抗，并且也是电容器。据推测，它们在相邻引脚之间的耦合足以使相邻引脚切换得足够快，这可能会将电荷驱动到输入引脚上并将其推入“热”状态。可能有一半的I / O引脚被驱动到该状态会使芯片预热到足以造成损坏的程度？

（是否存在一种模式，其中开路的电路引脚的电容可以像倍压器一样使用？嗯。）

我也认为损坏的闪光灯就足够了。我认为那太糟糕了，以至于无法使用该芯片。

它不需要全部刷新，而只需包含上电，RESET等向量的页面即可。一页上的限制可能需要几十秒。

我有迹象表明，但没有确凿的证据）对于某些MCU来说，情况可能更糟。几年前，我参加了一个演讲。有人问为什么竞争对手提供的零件具有更高的闪存写入周期。这位（大型未具名的MCU制造商）发言人表示，他们在闪存规格方面采取了非常保守的方法。他说，他们的保证书所规定的温度要比行业标准高得多。有人问“那又怎样”。发言人说，在相同的温度下，几种制造商产品的重写寿命将大大低于其零件的重写寿命。我的回忆是5倍会变成<1倍。他说这是非常非线性的。我认为这意味着在80C而不是25C进行编程将是“一件坏事”。

So, flash rewriting combined with a very hot chip, might also render it useless in less than 10 seconds.

Edit:
I think "releasing the blue smoke of death" is a harder constraint than required. If any of the: RESET pin circuit, brown-out-detector, power-up circuitry, RC or crystal oscillator (and probably a few other circuits) could be damaged, the chip would be rendered useless.

As others have noted, breaking flash would kill it irreparably too.

"Smoke" sounds impressive, but less obvious fatal attacks are still fatal, and much harder to detect.

One potential source of such destruction is SCR latchup, where unintended (intrinsic) transistors in a chip get together to form a kind of TRIAC which can then sink a lot of current. This can easily blow bond wires, and I've even seen plastic encased devices visibly warped because of the heat produced.

The typical cause is driving (even momentarily) an input to above or below the supply or ground rails respectively, but I guess you might see it happen if an input was left floating. And it's not then hard to imagine a circuit where the input's floating-ness was software controlled (although that would be a very silly thing to allow).

It's POSSIBLE that software intentionally written for the purpose, targeted at a very specific processor, might be able to force overclocking to the point at which the processor would overheat. Provided, of course, that the processor contains software-configurable clock-control registers.

It's NOT possible that ALL processors can be damaged this way, of course. If that were true, there'd've been billions of Z80s and 6800s and 6502s laid by the wayside by wayward software-writing tyros back when we were still typing in machine code manually, making lots of random mistakes.

This is my entry for ruining a microcontroller with as few parts as possible...

Just toggle the output pins at a few kHz!

You still might not see smoke, depending on the internal failure mode though.

^{simulate this circuit – Schematic created using CircuitLab}

--Edit, added Aug 22--

Now, I don't think you can ruin a microcontroller with the criteria given. But you can EASILY ruin external circuitry with the wrong code. A example that comes to mind is a simple boost converter I designed recently... simply pausing the code while debugging could short an inductor to ground through a MOSFET. POOF

In terms of regular user mode code I don't think you can write anything that will break the chip.

However, I do remember the days of microprocessors that could be destroyed in less than a minute or even seconds if the heat sink fell off. Then they added thermal detection circuits that would turn the clock down if the part got too hot. Now that we're able to put in far more transistors than can be used at once, chips are capable of making more heat than the heat sink can dissipate and its the power management and thermal circuits that keep it safe. For example, see Intel Turbo Boost 2.0. Therefore it seems quite possible to melt down a chip if you're able to bypass or raise the limit on the power management and thermal circuit. So, if these are under software control (no idea; maybe it requires a BIOS update?) then you could run a bunch of parallel do-nothing loops, along with integrated GPU work, along with hardware H.264 decoding and encoding, and anything else the chip can do, all at once until the chip overheats and emits the magic blue smoke.

I'm most familiar with the STM32 processors, so these apply most to that family. But similar approaches may be possible with other processors also:

1. There is a permanent write-protect mode. So if you program that bit, and some useless program to the FLASH, the MCU can never be used again. I don't know if this counts as 'bricking', but it does involve a permanent hardware mechanism.

2. The programming pins are reconfigurable as GPIO. Because the clock pin is driven by the programming device, this could be used to cause a short-circuit. Most probably it would break that single pin, which being a programming pin would be quite bad.

3. Like mentioned by dirkt, the PLL's can be used to overclock the processor. This could possibly cause it to overheat or otherwise get damaged.

Who ever told that that doesn't understand how involved the design process is of such chips. That doesn't mean that slip up don't happen and that the code coverage of the regressions and corner cases sometimes miss things, but to make a statement that ALL or even most processors have this flaw is logically dubious.

Just ask yourself, what happens when an over-clocker exceeds timing requirements (assuming it doesn't overheat). the chip fails, and perhaps corrupts memory and even HDD access but fundamentally the processor will fire back up again and even run the OS again if the corruption is fixed. So what sort of properly designed microcode could possibly cause MORE disruption than this scenario? - answer very likely none.

TLDR; All processors have this fault - NOT

I believe that it is certainly possible to physically destroy a micro-controller (MC) with software. All that is required, is the combination of the MC to be executing a "tight" loop of instructions that cause 100% utilization, and a "defective" heat-sink which allows the heat inside the chip to buildup. Whether the failure takes seconds, minutes or hours, will depend on how fast the heat builds up.

I have a laptop computer that I can only use it a 50% continuous utilization. If I exceed this, the computer shuts itself down. This means that at 50% usage the MC temperature is below the set trigger point. As the usage increases, the temperature of the MC increases until the trigger point is reached. If the thermal shut down circuit did not work (or did not have one), the temperature of the MC would keep on increasing until it got destroyed.

^{simulate this circuit – Schematic created using CircuitLab}

#include <avr/io.h>

int main(void)
{
    DDRB |= _BV(2) | _BV(4);
    PORTB |= _BV(2);
    PORTB &= ~_BV(4);
    for (;;);
}

The code above causes the MCU to push PB2 high while pull PB4 low, and this creates a short circuit from VDD to PB2 to PB4 to GND and quickly the port drivers of PB2 and/or PB4 will fry. The short circuit may be an innocent error like accidental soldering bridge.