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
Reply by ●May 15, 20122012-05-15
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
Reply by linnix●May 12, 20122012-05-12
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.
Reply by Ulf Samuelsson●May 11, 20122012-05-11
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
Reply by linnix●March 23, 20122012-03-23
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
}
Reply by linnix●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.
Reply by Meindert Sprang●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 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!
>
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 Laszlo●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
>
> 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
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