Atmega328p-PU losing its programming

Hi.. For some reason my chip is losing its programming because if I re-upload the sketch it starts works again.. and randomly after 1, 2 or 10 days it lose its programming again..

I'm running atmega328p-PU @ 8Mhz and fuses to works @ 8Mhz and 1.8v brown-out.

Maybe a bad chip quality?

Any Idea?

Tks!

Are you certain that a powercycle or Reset does not restore operation and it really does require reprogramming? The PROGMEM flash area is pretty robust. Are you doing anything with high voltages that may be zapping the chip, such as with a relay, motor, or other inductive load?

Do you have anything connected to the serial pins that may be confusing the bootloader? (Do you use the bootloader or are you programming with ISP)?

Do you have anything connected to the ISP pins that may be inadvertently putting the chip into programming mode?

Are you using EEPROM in your program at all?

Do you have decoupling caps on the VCC and ground pins?

Do you have a pullup resistor on the Reset pin?

Hi.. First of all, thank you for your answer!

Well. Lets see..

Are you certain that a powercycle or Reset does not restore operation and it really does require reprogramming? No it doesn't. I can try to powercycle 100 times and doesn't work. at all.

The PROGMEM flash area is pretty robust I'm not using any PROGMEM

Are you doing anything with high voltages that may be zapping the chip, such as with a relay, motor, or other inductive load? No. I'm using to drive a display and a I2C sensor..

Do you have anything connected to the ISP pins that may be inadvertently putting the chip into programming mode? Actually I don't know exactly... (wich pin are the ISP pin on atmega328?) honestly I don't know...

Are you using EEPROM in your program at all? Yes to store some settings info.

Do you have decoupling caps on the VCC and ground pins? No.. when turned on they are connected direct to the + and -

Do you have a pullup resistor on the Reset pin? The Reset Pin us connected to + by a 5k resistor.

Please if you have any idea, please let me know..

Tks a lot!

Actually you are using PROGMEM. That's where your compiled C code goes, and is executed from. :)

Since you are using EEPROM, you may be writing a value to it that you don't expect when you later go to read it out. This can cause your program to hang, which appears to make the chip unresponsive. I believe re-programming the chip erases the EEPROM, which might be clearing this condition.

The ISP pins are 11, 12, and 13 (and LED on 13 is harmless).

I'm not sure I understand your answer about the decoupling caps. They should be present on both sets of +/- pins as shown here:

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

Also, are you using the Arduino bootloader, or are you programming the chip with an ISP?

Hi! Well. tks.. but I didn't know the compiled code is stored in PROGMEM.. one more for my knowledge :) tks for that!!!

Whats its weird is the fact of the problem is randomly and I have another projects running for months without any issue!

About caps, you mean, capacitors?

No i'm not using any...

Just connect pin 7, pin 20 and Reset to + and Pin 8 and 22 to GND

And yes I'm using Arduino as ISP.

First I burn the bootloader for brang new chips and then upload sketches using arduino.

Thank you very muc for sharing your knowledge!

Rodrigo

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).