Electronic – Is it possible to physically destroy a microcontroller with software

damagemicrocontrollersoftware

Assumptions:

No external circuitry connected (other than the programming circuit, which we assume to be correct).
uC is not faulty.
By destroying I mean releasing the blue smoke of death, not bricking it in software.
It's a "normal" uC. Not some very weird 1-in-a-million very purpose specific device.

Has anyone ever seen something like that happen? How is it possible?

Background:

A speaker of a meetup I assisted to said it was possible (and not even that hard) to do this, and some other people agreed with him. I have never seen this happen, and when I asked them how it was possible, I didn't get a real answer. I'm really curious now, and I'd love to get some feedback.

Best Answer

Of course you can, with the HCF instruction!

That said, I say that's impossible without any external circuitry, apart from power and such.

Even including some non purposely faulty connections possibly won't cut it: if you tie all the gpios to a power rail, setting them as output (to the opposite power rail) that can dissipate quite a lot of power. A gpio pin is probably protected against short circuit and such so nothing harmful will happen.

Designing an external circuit that destroys the chip at will is not trivial too in my opinion. The first thing that comes to mind needs a somewhat high voltage power supply, a nmos and a resistor:

schematic

^{simulate this circuit – Schematic created using CircuitLab} Where:

\$V_{CC}\$ is the usual supply for the micro, some 3v3 to 5V or whatever is needed
HV is a supply which voltage is well above the absolute maximum ratings of the micro
D1 is there to protect your valuable 3V3 voltage source
R1 pulls the mosfet gate high when the micro is not keeping it to ground
M1 is the designated killer

the operation is simple: if the micro releases GPIOx M1 turns on, Vcc rises and your chip catches fire. Note that this is a crappy setup, for example HV must be turned on after you are extra sure that GPIOx is firmly held to ground. Some transistors might not like some -5V Vgs, and so on... But you get the picture.

Related Solutions

Electronic – Random microcontroller deaths

There are several reasons why microcontrollers would act as described above. The three most common causes are:

You are trying to supply too much power. Putting 12 volts into a 5 volt chip will kill it instantly, for example.
Your loads are drawing too much current. The microcontrollers can only source a certain amount of current, and trying to draw more than that (for example, trying to run a motor directly from the chip's output) will likely cause it to burn out.
Shorted pins

To fix these issues, try the following:

Most microcontrollers require either 3.3V or 5V to operate. Check your chip's datasheet to make sure you're not supplying too much power.
If you're driving large loads, like motors or coils, use a transistor connected (through a base resistor) to the microcontroller. Then you can control the transistor with the microcontroller, but the load will draw its power from the main power supply instead of from the chip.
Check that your wiring is correct. Ensure no pins are touching, that you don't have any solder bridges (if your chip is soldered into a circuit), etc. Make sure the schematic is followed exactly.

The problem you are facing most likely stems from one of the above problems, so check through them and see if they help.

Electronic – Software timers and interrupts on a microcontroller

You do not need special "software interrupts". Have a look at the following code. I neglected some technical stuff like variable declaration for clarity.

Use your ISR to just count some timer (tick). In the main() you are waiting to sync to this timer. Use a dedicated timer for each task you have to process. All these timers are incremented every ISR tick.

If the task timer expire, the dedicated task is processed. There are some special features in this kind of implementation. When you subtract the EXPITED-time from your timer instead setting it to be 0, your software is more robust if any of the tasks takes longer thenn 100µs. It's a kind of soft-realtime criteria.

You get a pseudo multi-tasking system.

isr() //100µs
{
    tick++;
}

main()
{    
  while(true)
  {
    while(tick == last_tick);
    last_tick = tick;

    modbus_timer++;
    task1_timer++;
    task2_timer++;

    if(modbus_timer >= MODEBUS_TIMER_EXPIRED)
    {
      modbus_timer -= MODEBUS_TIMER_EXPIRED;
      Modbus_Protocol();
    }

    if(task1_timer >= TASK1_TIMER_EXPIRED)
    {
      task1_timer -= TASK1_TIMER_EXPIRED;
      Task1();
    }

    if(task2_timer >= TASK2_TIMER_EXPIRED)
    {
      task2_timer -= TASK2_TIMER_EXPIRED;
      Task2();
    }
  }//forever-loop
}// main()