Atmel, ATMEGA88-20AU. 32 TQFP package.

On Mar 22, 10:25=A0am, linnix <m...@linnix.info-for.us> wrote:
> 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 atm=
ega
> > and the internal eeprom. I've seen this issue about 10years ago first o=
n
> > the old ATMEGA8 family, the IC was very susceptible to noise from the p=
ower
> > 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 year=
s
> > 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 li=
ke
> > 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 proje=
cts
> > with atmel48/88.
>
> Yes, i am a true Atmel believer except for the bugs in data specs and
> ICs. =A0Atmel chips are good enough for prototypes. =A0But for mission
> critical apps, you have to be careful. =A0I've seen both FLASH and
> EEPROM corruptions for no reasons. =A0For 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. =A0We could have used the OTP chip
> for the app, but it doesn't have all the Atmel features.

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<<EEWE))
		;
	EEAR =3D a; // address register
	EECR |=3D (1<<EERE); // read enable

	return EEDR; // data register
}

void ee_write(unsigned short a, unsigned char d)
{
	// Prev. write busy
	while(EECR & (1<<EEWE))
		;
	EEAR =3D a; // address register
	EEDR =3D d; // data register
	EECR |=3D (1<<EEMWE); // master write enable
	EECR |=3D (1<<EEWE); // write enable
}

Laszlo skrev 2012-03-20 12:55:
> 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.
>
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

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

On May 11, 2:21=A0pm, Ulf Samuelsson <ulf_samuels...@invalid.telia.com>
wrote:
> Laszlo skrev 2012-03-20 12:55:
>
>
>
>
>
>
>
> > Hi,
>
> > I just bumped into this topic, and want to share my experience with atm=
ega
> > and the internal eeprom. I've seen this issue about 10years ago first o=
n
> > the old ATMEGA8 family, the IC was very susceptible to noise from the p=
ower
> > 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 year=
s
> > 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 li=
ke
> > 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 proje=
cts
> > with atmel48/88.
>
> 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
>
>
>
>
>
>
>
>
>
> >> 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. =A0On power up, the module stays in reset until VCC reach=
es
> >>> 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 le=
ss
> >>> 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.
>

External brownout detector would defeat the advantage of single chip
with internal EEPROM.  I use internal brownout detector, but can't
stop it from losing memory sometime.  This is especially true with it
running at 5V (AC adapter).  Running at 3.6V or below seems to be
better.

On Saturday, May 12, 2012 9:21:14 AM UTC+12, Ulf Samuelsson wrote:
> 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.

 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

On 2012-05-15 06:46, j.m.granville@gmail.com wrote:
> On Saturday, May 12, 2012 9:21:14 AM UTC+12, Ulf Samuelsson wrote:
>> 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.
>
>   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 ?
>

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.


>   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