Atmel, ATMEGA88-20AU. 32 TQFP package.

Power sequencing or noise, perhaps.

Have somebody else look at the software. A second pair of eyes is sometimes worth its weight in gold.

--
John B

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

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 wrote:

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

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.

--------------------------------------- Posted through

power

user

and

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

a

er

t o

er

nd

s

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.

ega

n

ower

But

s

to

user

ke

and

)

cts

By the way, i have not been able to write to EEPROM from program for an Atmega169. Reading from program is OK and Read/Write from SPI programming is also OK. Either the spec is wrong or the chip is buggy. Anyone has ideas? Examples from datasheet:

unsigned char ee_read(unsigned short a) { // Prev. write busy while(EECR & (1

Laszlo skrev 2012-03-20 12:55:

You are aware that there has been significant redesign of those protions of the chip, resulting in the ATmega88P and ATmega88PA? If you are worried, you should move on the later families.

If you read the datasheets of older parts carefully, you will see that if Brownout occurs, you have to bring down Vcc to below 50 mV (or so). With modern devices it is enough to bring it down to 0.5-0.6V.

BR Ulf Samuelsson

Do you mean such deep Vcc cycling is needed for the On-chip Brown-out to function 'correctly', or does this apply to fuse-read as well, and so will also affect any external RESET generator ?

Such a spec suggests a power-removal reset is the only safe solution ? ( and I've often wondered why more regulators do not work in this manner )

-jg

No, it is to ensure that the part properly exits from the power-on reset when the power is returned. If you don't then the part might lock up.

This is the default behaviour of most MCU power on resets from all manufacturers.

If the power drops slightly below the triggerlevel, and then returns to proper power, the part might lock up until power cycled. I have not heard anyone but Atmel document it.

Maybe some people have had problems with their home electronics, called in, and are then told to remove the power cord wait one minut and the reinsert. You also see the phenomena in remote controls at the end of the battery life. You press a button, which will sink the voltage level, and the MCU will enter reset, but will not exit reset and will not issue more IR until power cycled.

When you remove the battery and reinsert, it will again work for a short time.

The Home Electronics guys *knows* about this problems.