Atmega328p-PU losing its programming

Yes, caps = capacitors.

"Random problems" and "no bypass capacitors" are often correlated. The capacitors may or may not be your problem, but you need to add the capacitors to eliminate that as a possibility.

If the problem remains even with the bypass caps in place, I'd be looking into your EEPROM reading code to make sure that an unexpected EEPROM value doesn't send you into an infinite loop or something.

Thumbs up for the above. I once had an arduino being fed up from some procell (Yes duracell crap batteries) cells driving a motor. The one with the good decoupling would restart randomly. The one without the decoupling would corrupt the flash memory for some reason..

Second idea is to re-check your fuses. Why are you setting the watchdog to 1.8V? Thats pretty unstable even to 8Mhz, might do crazy things.

tylernt: Yes, caps = capacitors.

"Random problems" and "no bypass capacitors" are often correlated. The capacitors may or may not be your problem, but you need to add the capacitors to eliminate that as a possibility.

If the problem remains even with the bypass caps in place, I'd be looking into your EEPROM reading code to make sure that an unexpected EEPROM value doesn't send you into an infinite loop or something.

So I just need to connect parallel caps into chip supply + and -?

I'll try to do that and see!

Tks a lot

casemod: Thumbs up for the above. I once had an arduino being fed up from some procell (Yes duracell crap batteries) cells driving a motor. The one with the good decoupling would restart randomly. The one without the decoupling would corrupt the flash memory for some reason..

Second idea is to re-check your fuses. Why are you setting the watchdog to 1.8V? Thats pretty unstable even to 8Mhz, might do crazy things.

Hi.. On this project actually I Don't need to run at 1.8 minimum but It is ..even using 3.3v regulator... But datasheet says it can be used, right? Do you think its still dangerous?

tks a lot

Yes, one 0.1uF cap on each of the two +VCC/-Ground pin pairs on the chip.

Got it! Tks… I’ll try this… the problem now is that I have 100 PCBS ready to go! I’ll have to deal with eventual problems on that!

cabecinhas: But datasheet says it can be used, right? Do you think its still dangerous?

Not guaranteed, so you are risking there. Datasheet says 10Mhz down to 2.7V and 4MHz down to 1.8V. And quite likely some changes in the oscillator fuses as well to avoid the oscillator stopping at such low voltages.

cabecinhas: ...the problem now is that I have 100 PCBS ready to go! I'll have to deal with eventual problems on that!

Not the best practice there, so surely something to check on future. If you want to save yourself the hassle design the PCB to fit a mini. All the power regulation elements are already there.

tylernt: Yes, one 0.1uF cap on each of the two +VCC/-Ground pin pairs on the chip.

With special attention to the analog supply as this may cause strange issues.

Now its all understood!

I’ll try to down te clock to MHz to be more comfortable @1.8v and check it I can put some caps !

I think you guys for all the suggestions!

:slight_smile:

Just forgot, Are you using an external crystal or the internal oscillator? If you don't mind much with accuracy running on the internal oscillator causes way less noise and glitches on the supply, so that could offer you more stability. On the other hand serial baud rates over 57600bps (at 8MHz) may be a problem. You can calibrate the oscillator, but a hassle to do individually on so many PCB's

Best of Luck

Hi, Casemod.

Yes I'm using internal internal oscillator @8MHz.

I'm not sure if the problem is the fact I'm not using caps because this would cause the chip to restart, right? And It's not.

My first thought was a bad quality atmega328 but I have never heard anything about it anyway :)

Can you define "loses its programming"? How do you know it does that? What you mean, do you not, is that it stops working? That would look similar to losing its programming.

To be certain it had "lost its programming" you would have to hook it up to an ICSP device (like USBtinyISP), read all its program memory (PROGMEM) back onto a file, and compare that to the one you originally uploaded (and have them differ). Have you done that?

Here are some things that might make the chip unresponsive:

  • Insufficient decoupling capacitors (as mentioned above)
  • No pull-up resistor on reset
  • A watchdog timer firing, preventing it from restarting properly
  • Brown-out detection kicking in
  • A bug. You should post your code.
  • Some electrical issue, for example a floating input making the code think a switch was being pressed a million times

How to use this forum

I'm not sure if the problem is the fact I'm not using caps because this would cause the chip to restart, right? And It's not.

How do you know that? If there is a bug, restarting won't make the bug go away.

There is also a recommendation for a diode between reset and +5V as shown here:

Without that, a voltage spike on reset may cause the chip to go into "high voltage progamming" mode and effectively go dead (for the moment).

If you can only resolve the issue by reprogramming, I'm inclined to guess you are using the watchdog timer, but without any posted code that is just a guess.

cabecinhas: Hi, Casemod.

Yes I'm using internal internal oscillator @8MHz.

I'm not sure if the problem is the fact I'm not using caps because this would cause the chip to restart, right? And It's not.

My first thought was a bad quality atmega328 but I have never heard anything about it anyway :)

Could do all sorts of strange things. What happens is data corruption. You can't see it but at random times the supply can drop or increase to all sorts of values during a few ns or ms. This has to do with the power source impedance, PCB tracks, power consumption, natural switching of the internal pins on and off and most importantly ESD since there is no low impedance path for this short HV peaks to flow, other than the chip itself. Have a look on wikipedia on how flash memories work and what happens after they are work out. Leakages. Just the same as a ns pulse may do.

Electrolytic reserve capacitors are an optional extra that should be placed as good practice. Ceramic decoupling capacitors are a must required for correct operation and should ALWAYS be placed.

The other possible issue is the bootloader not being correctly write protected. There is a locked area of the memory set by fuses. If incorrectly programmed the bootloader itself can get deleted and the chip wont start. But this will typically happen during upload of new code. The code is there, but without the bootloader it will never execute it and you cant update new code either.

Good point about corruption of the bootloader. However the test I proposed above (reading the chip contents back) would confirm whether or not this is happening (of course you would read the bootloader as well).

I have a sketch that gets a sumcheck of the bootloader:

http://www.gammon.com.au/forum/?id=11633

Flash and EEPROM programming use an on-chip boost converter to generate the programming voltages and these require a minimum supply voltage to operate correctly. The datasheet mentions that programming flash or EEPROM can be unreliable if the voltage is too low.

This means as mentioned you must have adequate decoupling in place, right next to the chip. 0.1uF ceramic per supply pin and 10+uF electrolytic/electrolytic for the board. This is a general precaution for any board with logic chips on it, BTW.

You should program at 5V supply rather than 3.3V if you can. If I'm flashing a bootloader I do it twice in a row to burn it in more solidly (I don't know if it makes any difference, but it shouldn't hurt).

MarkT: You should program at 5V supply rather than 3.3V if you can. If I'm flashing a bootloader I do it twice in a row to burn it in more solidly (I don't know if it makes any difference, but it shouldn't hurt).

We're being superstitious here. Nothing wrong with a 3.3V supply for programming. I have long ago stopped using 5V and all my arduinos run at 3.3V with zero problems, one at 24Mhz, although I do so at my own risk.

Also the bootloader is checked during programming, re-burning wont do anything but erode the internal flash cells. Thats similar to suggesting to delete contents on a flash drive and copy them twice just to make sure they get there. If a mismatch is found the software will return an error, unless verification is disabled, which is not default.

The issue is the datasheet mentions there is a minimum voltage for programming, but fails to say what it is... There seems to be an implication that the supply must be held constant during programming (several ms), and I haven't found what the supply current is during EEPROM or Flash programming either, it might impose extra load on the regulator for instance.

MarkT: The issue is the datasheet mentions there is a minimum voltage for programming, but fails to say what it is...

What!? :fearful:

Serial programming section = +1.8 to +5.5V

Power consumption: Section 27 - There's a nice graph showing programming current versus temperature.

Very good, but I doubt the chip has "lost" its program.