Hi, The EEPROM in Atmel, ATMEGA88-20AU. 32 TQFP package is not functioning well. It works okay but sometimes it gets the garbagge data from micro . Does anybody know whether is it related to PCB issue, or soe hardware issue. I checked the software many times, i did not finnd anything wrong. Regards, John
Atmel, ATMEGA88-20AU. 32 TQFP package.
Started by ●November 6, 2008
Reply by ●November 6, 20082008-11-06
On Nov 6, 1:17 pm, john <conphil...@hotmail.com> wrote:> Hi, > > The EEPROM in Atmel, ATMEGA88-20AU. 32 TQFP package is not > functioning well. It works okay but sometimes it gets the garbagge > data from micro . Does anybody know whether is it related to PCB > issue, or soe hardware issue. I checked the software many times, i did > not finnd anything wrong. > > Regards, > JohnPower sequencing or noise, perhaps.
Reply by ●November 7, 20082008-11-07
On 06/11/2008 john wrote:> Hi, > > The EEPROM in Atmel, ATMEGA88-20AU. 32 TQFP package is not > functioning well. It works okay but sometimes it gets the garbagge > data from micro . Does anybody know whether is it related to PCB > issue, or soe hardware issue. I checked the software many times, i did > not finnd anything wrong. > > Regards, > JohnHave somebody else look at the software. A second pair of eyes is sometimes worth its weight in gold. -- John B
Reply by ●November 11, 20082008-11-11
Hi, The power sequence is as follows Reset pin is disconnected and I have the 4.3V low voltage fuse programmed. On power up, the module stays in reset until VCC reaches 4.3V. On power down, the micro operated down to 4.3V and then goes into reset. So the micro is always in the rest mode when VCC is less then 4.3V. Is the above scheme ok? Regards, John
Reply by ●November 12, 20082008-11-12
On Nov 11, 1:26=A0pm, john <conphil...@hotmail.com> wrote:> Hi, > > The power sequence is as follows > > Reset pin is disconnected and I have the 4.3V low voltage fuse > programmed. =A0On power up, the module stays in reset until VCC reaches > 4.3V. =A0On power down, the micro operated down to 4.3V and then goes > into reset. =A0So the micro is always in the rest mode when VCC is less > then 4.3V. > > Is the above scheme ok? > > Regards, > John
Reply by ●November 12, 20082008-11-12
John - can't offer any evaluation of the power on sequence you described. However, with an atmega48 an intermitent error was occuring. Some code that caused a hesitation immediately after reset and before anything else was done fixed or at least removed the error. My intent was, I believe, to stall for 1 second. A quick look at the code looks like 2 seconds, though. Hul john <conphiloso@hotmail.com> wrote:> On Nov 11, 1:26?pm, john <conphil...@hotmail.com> wrote: > > Hi, > > > > The power sequence is as follows > > > > Reset pin is disconnected and I have the 4.3V low voltage fuse > > programmed. ?On power up, the module stays in reset until VCC reaches > > 4.3V. ?On power down, the micro operated down to 4.3V and then goes > > into reset. ?So the micro is always in the rest mode when VCC is less > > then 4.3V. > > > > Is the above scheme ok? > > > > Regards, > > John
Reply by ●November 13, 20082008-11-13
On 11/11/2008 john wrote:> Hi, > > The power sequence is as follows > > Reset pin is disconnected and I have the 4.3V low voltage fuse > programmed. On power up, the module stays in reset until VCC reaches > 4.3V. On power down, the micro operated down to 4.3V and then goes > into reset. So the micro is always in the rest mode when VCC is less > then 4.3V. > > Is the above scheme ok? > > Regards, > JohnI suspect your problem lies with the RESET pin floating. If you are only using the internal brownout detector the connect the RESET pin to VCC. However I would advise against such a procedure and use an external brownout detector such as a MAX809. -- John B
Reply by ●March 20, 20122012-03-20
Hi, I just bumped into this topic, and want to share my experience with atmega and the internal eeprom. I've seen this issue about 10years ago first on the old ATMEGA8 family, the IC was very susceptible to noise from the power line and was going crazy, eeprom corruption, chaotic execution, reset. But to keep on-topic, the eeprom corruption, i red on some topic a few years ago that the old atmega family had some internal sync. error, the clock to the eeprom and the main clock or something similar. When slow power on/power down some garbage could be written in the eeprom, without any user software intervention. I believed that this was solved in the next generation atmega(48,88,..), i didn't saw this behavior with the atmega48,88 regardless of the package. For the old atmega my general solution was: use an external reset IC like MCP130(with internal pull-up), the internal brown-out doesn't help much and don't ever rely only on the simple external R/C reset! For critical applications i always added the external reset IC, and for harsh environments like induction heating control i used microchip (PIC) products, newer heard anybody complaining about similar problems with microchip ic's and i was a true atmel believer i built most of my projects with atmel48/88.>On 11/11/2008 john wrote: > >> Hi, >> >> The power sequence is as follows >> >> Reset pin is disconnected and I have the 4.3V low voltage fuse >> programmed. On power up, the module stays in reset until VCC reaches >> 4.3V. On power down, the micro operated down to 4.3V and then goes >> into reset. So the micro is always in the rest mode when VCC is less >> then 4.3V. >> >> Is the above scheme ok? >> >> Regards, >> John > >I suspect your problem lies with the RESET pin floating. If you are >only using the internal brownout detector the connect the RESET pin to >VCC. However I would advise against such a procedure and use an >external brownout detector such as a MAX809. > >-- >John B >--------------------------------------- Posted through http://www.EmbeddedRelated.com
Reply by ●March 21, 20122012-03-21
"Laszlo" <laszlo.fabian@n_o_s_p_a_m.gmail.com> wrote in message news:oKGdnQ6oc8e77fXSnZ2dnUVZ_u-dnZ2d@giganews.com...> Hi, > > I just bumped into this topic, and want to share my experience with atmega > and the internal eeprom. I've seen this issue about 10years ago first on > the old ATMEGA8 family, the IC was very susceptible to noise from thepower> line and was going crazy, eeprom corruption, chaotic execution, reset. But > to keep on-topic, the eeprom corruption, i red on some topic a few years > ago that the old atmega family had some internal sync. error, the clock to > the eeprom and the main clock or something similar. When slow power > on/power down some garbage could be written in the eeprom, without anyuser> software intervention. I believed that this was solved in the next > generation atmega(48,88,..), i didn't saw this behavior with the > atmega48,88 regardless of the package. > > For the old atmega my general solution was: use an external reset IC like > MCP130(with internal pull-up), the internal brown-out doesn't help muchand> don't ever rely only on the simple external R/C reset! >I have seen the same behaviour with the AT90S8515 and the ATmega8515. I only had a pull-up on the reset and a small cap to ground, as per datasheet, to allow ISP programming. In a marine environment where the product was used (battery power, engine started from the same battery) the device regularly lost its config stored in EEPROM. Enabling the brown-out detection (set to 4.3V) solved the problem forever. No need for an external reset IC. Meindert
Reply by ●March 22, 20122012-03-22
On Mar 20, 4:55=A0am, "Laszlo" <laszlo.fabian@n_o_s_p_a_m.gmail.com> wrote:> Hi, > > I just bumped into this topic, and want to share my experience with atmeg=a> and the internal eeprom. I've seen this issue about 10years ago first on > the old ATMEGA8 family, the IC was very susceptible to noise from the pow=er> line and was going crazy, eeprom corruption, chaotic execution, reset. Bu=t> to keep on-topic, the eeprom corruption, i red on some topic a few years > ago that the old atmega family had some internal sync. error, the clock t=o> the eeprom and the main clock or something similar. When slow power > on/power down some garbage could be written in the eeprom, without any us=er> software intervention. I believed that this was solved in the next > generation atmega(48,88,..), i didn't saw this behavior with the > atmega48,88 regardless of the package. > > For the old atmega my general solution was: use an external reset IC like > MCP130(with internal pull-up), the internal brown-out doesn't help much a=nd> don't ever rely only on the simple external R/C reset! > > For critical applications i always added the external reset IC, and for > harsh environments like induction heating control i used microchip (PIC) > products, newer heard anybody complaining about similar problems with > microchip ic's and i was a true atmel believer i built most of my project=s> with atmel48/88. >Yes, i am a true Atmel believer except for the bugs in data specs and ICs. Atmel chips are good enough for prototypes. But for mission critical apps, you have to be careful. I've seen both FLASH and EEPROM corruptions for no reasons. For our current app, we plan on using an external OTP (One Time Programmable) chip to verify the FLASH and to store data in external EEPROM. We could have used the OTP chip for the app, but it doesn't have all the Atmel features.