Which are the causes for bricking a working ATMega328?

Hello,

I'm using the ATMega328 since long time but there is a curiosity that often jumps in my mind...
Let's suppose that I have a working uC, with a working code and I'm happy with it.
Occasionally it happens that the uC stops working after a power cycle.
It seems like the bootloader get damaged somehow since I'm not able to upload any sketch using the IDE.
After burning the bootloader, I'm able to flash through the IDE and everything come back to life!

What could cause this strange situation?
Are there any known causes that are related to damaging the code or "bricking" the uC?
Too much current from pins? Too high voltage? I have no idea ant it seems to be non-reproduceable!

Anyone has any advice?Preformatted text

With a normal Arduino configuration of the microcontroller, the only way I know of to accomplish this via the firmware is triggering this watchdog reset handling bug in the old "ATmegaBOOT" bootloader:

I've often wondered how likely it is for out of spec conditions to corrupt the bootloader while not being severe enough to cause significant physical damage to the microcontroller.

We see lots of reports from people who suddenly can't upload to their previously functional ATmega328P/ATmega2560-based boards (the situation is different with other boards) and it is common advice to burn the bootloader after the more simple possible solutions have been exhausted.

There are sometimes reports, including yours, of this solving the problem. But I also see a lot of beginners having tremendous difficulties with the bootloader burning process. I think often they have simply let the smoke out of their boards and they would be better off to get a new one and move forward rather than losing momentum struggling to recover a board that is a lost cause.

We see lots of reports from people who suddenly can't upload to their previously functional ATmega328P/ATmega2560-based boards (the situation is different with other boards) and it is common advice to burn the bootloader after the more simple possible solutions have been exhausted.

There are sometimes reports, including yours, of this solving the problem.

Thank you for your quick reply, however the question is still there... What might be the reason?
PS: I couldn't find many thread talking about that...

I do not know the exact bootloader logic. However there are a few ways to do this.

  1. Overwrite the flash
  2. Corrupt the linker
  3. Configuration bits
  4. Have bad hardware state, which causes brown out or reset event
  5. Watchdog (Bootloader could block this.)
  6. Kill a section of flash from too many writes.
  7. Blow up pins.
  8. Put noise on programming lines.
  9. Trick the programmer into uploading code for the wrong device/configuration.
  10. Use incorrect voltage for frequency.

Probably many more ways.

Reset events are supposed to stop certain things. If they do not there could be a boot loop or crash there. Usually this will not brick the bootloader if power reset.

Does it continue to do what it was doing, if you power cycle without programming? What is connected to it when programming?

I remember in one specific design, it was basically connected to potentiometers and one mosfet (straight to its gate) to drive a brushed motor.
Some time it used to work fine, other time I turned on and I could notice the motor spinning constantly instead of just give it just a short pulse…
In that case i had to reflash the fw (not the bootloader).

Another possibility might be static electricity.

No series resistor?

A sketch can theoretically NOT overwrite the flash. Only the bootloader (or a device programmer) can write flash. (I'll assume you haven't installed that bootloader upgrade that allows calling it to write flash.)

  1. Corrupt the linker

I'm not sure what that means. "The linker" is normally one of the build tools, and nothing a build tool does should brick an AVR.

  1. Configuration bits

There should be no way to change the configuration bits ("fuses") without a device programmer. Even the bootloader can't do it.

The most common way to "brick" an AVR with a device programmer is to mis-configure the clock. Once configured for a clock that isn't there (say: "external oscillator" instead of "external crystal"), you're in trouble, because the clock is needed to do additional programming.
Also - turning on "debugWire" will stop ISP from working.

  1. Have bad hardware state, which causes brown out or reset event
  2. Kill a section of flash from too many writes.
  3. Use incorrect voltage for frequency.

These should be temporary issues that don't brick the chip. (Well, I guess if you connect Vcc to 48V, that would result in permanent damage.)

  1. Blow up pins.
  2. Put noise on programming lines.
  3. Watchdog (Bootloader could block this.)

These are more likely. In particular, there's a know bug in the old bootloader that would send chips into a watchdog reboot loop, and a hardware bug in some old boards (missing diode on RESET) that can cause the auto-reset feature to put the chip into HV programming mode. ( Regression between uno and uno R2 VALIDATED. HARDWARE PROBLEM CONFIRMED )

At no point did I use these words.

https://apastyle.apa.org/style-grammar-guidelines/citations/quotations/changes

Use square brackets, not parentheses, to enclose material such as an addition or explanation you have inserted in a quotation.

One possible explanation is that if you attempt to cure a "problem" by re-installing a bootloader using a programmer (as you must) then, while the programmer is still connected, upload your sketch, your sketch may well work. However, in the process, you will have lost the bootloader so subsequent attempts to load a sketch via the "normal" method fail.