AVR-Chat

I have a circuit using an AT90S2313 working on a very noisy 
environment and subject to program 'crashes' sometimes.
	The Watchdog is very efficient recovering from crashes, but
I'm having a corruption on the EEPROM contents.
	What is the best method of saving some bytes (2) in the internal
EEPROM and getting them back without corruption? Is there some sort
of FEC applied to memories?

	Thanks,
	Mark Jordan

At 10:25 PM 9/19/04 -0300, you wrote:
>         I have a circuit using an AT90S2313 working on a very noisy
>environment and subject to program 'crashes' sometimes.
>         The Watchdog is very efficient recovering from crashes, but
>I'm having a corruption on the EEPROM contents.
>         What is the best method of saving some bytes (2) in the internal
>EEPROM and getting them back without corruption? Is there some sort
>of FEC applied to memories?

National has (had?) an app note on this.  I'll look it up tomorrow (it's 
getting a little late).

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,
be they legal, genetic, or physical.  If you don't believe me, try to
chew a radio signal. "

                         Kelvin Throop, III

Use an external reset chip.  This is a well documented problem with first
generation AVR chips.  If you can't then a) don't use the first word of
EEPROM and b) always zero the EEAR register between operations.

Best, upgrade to a tiny26 or some other chip with a built in BOD.  I have
never had EEPROM problems with the new mega & tiny chips.

-----Original Message-----
From: Mark Jordan

	I have a circuit using an AT90S2313 working on a very noisy
environment and subject to program 'crashes' sometimes.
	The Watchdog is very efficient recovering from crashes, but
I'm having a corruption on the EEPROM contents.
	What is the best method of saving some bytes (2) in the internal
EEPROM and getting them back without corruption? Is there some sort
of FEC applied to memories?

At 10:25 PM 9/19/2004, Larry Barello wrote:

>Use an external reset chip.  This is a well documented problem with first
>generation AVR chips.  If you can't then a) don't use the first word of
>EEPROM and b) always zero the EEAR register between operations.

I wrote some code for the 8515 specifically to test for that old EE corruption issue. 
I never did get a hit. 

I suspect a lot of that was people starting writes immediately before a reset, or brownout. 

I do agree, set EEAR to zero when it's not in use, and don't use location 0.
It's cheap insurance.

At 11:19 PM 9/19/04 -0400, you wrote:
>At 10:25 PM 9/19/04 -0300, you wrote:
> >         I have a circuit using an AT90S2313 working on a very noisy
> >environment and subject to program 'crashes' sometimes.
> >         The Watchdog is very efficient recovering from crashes, but
> >I'm having a corruption on the EEPROM contents.
> >         What is the best method of saving some bytes (2) in the internal
> >EEPROM and getting them back without corruption? Is there some sort
> >of FEC applied to memories?

As promised the reference to the National app-note. It's AN482 on error 
detection and correction.  I've used their techniques on external ee in a 
noisy environment.  These are aimed more at single bit wearout type errors 
though, or single bit data stream corruption.  As a final resort detection 
of corruption it has a use but I think the base problems are not addressed 
by this.  The errors I've seen (and I have to say they weren't on internal 
atmel parts) appeared to be more extensive.  The approaches we took were

  - multiple copies of infrequently changing data (such as parameters), 
with fletcher checksums to detect changes.
  - Hamming code protection of frequently changing data (such as timers)
  - no protection of error codes

Even with this protection all copies of the parameters would occasionally 
get corrupted.  Further efforts led to
  - many code reviews looking for SW failures.  The SW would only turn off 
write protection for the time of the update of whatever location was being 
updated (and of course in the case of multiple copies the checksum/crc of 
the copy being updated would be updated before any other copies were modified)
  - extra decoupling capacitors added to the EE.

Each of those helped.  Part of the problem at this point is the error rate 
was small.  Only a few units a year.  In some cases the parameters would be 
customized so the default parameters would be the ones the customer would 
use and so any errors that would occur would not even be noticed.  Two more 
things were done though
  - the PC board was converted to four layers with power and ground planes. 
It appeared from the returns that this probably reduced the error rate by a 
factor of 2.
  - new designs switched to FRAM from EE.  The write time on FRAM is so 
much faster than the write time for EE (100ns as opposed to 5mS) that the 
window of vulnerability where the device is write enabled is very much 
shorter.  It looked like this was also making a difference but I wasn't 
around long enough to see enough data to be sure.

Some designs I've seen only write to non-volatile storage when the noise is 
low and they can be sure of power, essentially making parameter updates a 
task that can only take place when the equipment isn't running.

Note that the long write time of the EE means that if you write to the EE 
during normal operation you must be able to detect the power failing at 
least 5mS before you lose power to the micro and EE, otherwise you will 
interrupt in the middle of a write.  None of the EE for which I've read the 
documentation will guarantee what happens when you do that and if I recall 
correctly some of them explicitly warn that doing so may corrupt all of the 
EE contents.

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,
be they legal, genetic, or physical.  If you don't believe me, try to
chew a radio signal. "

                         Kelvin Throop, III

At 05:11 PM 9/21/04 +1000, you wrote:
>This App Note looks interesting. Unfortunately I have had no luck locating
>it on national.com using variations of the search 'an-482 error detection
>correction.
>Could you send a link to the place we can get it from.

National split EE's off to Fairchild and it looks like Fairchild obsoleted 
them and dumped the app notes.  I found someone with an archived copy.

http://manuales.elo.utfsm.cl/datasheet/national/pdf/nsc04320.pdf

It would probably be a goos idea to save a copy in case the archive disappears.

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,
be they legal, genetic, or physical.  If you don't believe me, try to
chew a radio signal. "

                         Kelvin Throop, III

Good thing most EEPROM now days has 100k cycles minimum and more like 1
million cycles - and that is at temperature and supply extremes.  Room temp,
normal operation is much, much better.

These issues apply to modern FLASH as well.  I was talking with a guy at
Cypress about their PsoC processor with ~30k cycles guaranteed on the FLASH.
He said at normal conditions the 10 year retention is well into many
millions of cycles.  It is only at the extremes (105C die temp, low Vcc)
that they get anywhere near the specified 30k cycles.

-----Original Message-----
From: Robert Adsett

At 05:11 PM 9/21/04 +1000, you wrote:
>This App Note looks interesting. Unfortunately I have had no luck locating
>it on national.com using variations of the search 'an-482 error detection
>correction.
>Could you send a link to the place we can get it from.

National split EE's off to Fairchild and it looks like Fairchild obsoleted
them and dumped the app notes.  I found someone with an archived copy.

http://manuales.elo.utfsm.cl/datasheet/national/pdf/nsc04320.pdf

It would probably be a goos idea to save a copy in case the archive
disappears.

This is exactly what the problem is, used to see this all the time,
external reset chip does the trick.  

Cheaper though to use a newer part.

-lp


--- In AVR-Chat@yahoogroups.com, "Larry Barello" <yahoo@b...> wrote:
> Use an external reset chip.  This is a well documented problem with
first
> generation AVR chips.  If you can't then a) don't use the first word of
> EEPROM and b) always zero the EEAR register between operations.
> 
> Best, upgrade to a tiny26 or some other chip with a built in BOD.  I
have

> never had EEPROM problems with the new mega & tiny chips.
> 
> -----Original Message-----
> From: Mark Jordan
> 
> 	I have a circuit using an AT90S2313 working on a very noisy
> environment and subject to program 'crashes' sometimes.
> 	The Watchdog is very efficient recovering from crashes, but
> I'm having a corruption on the EEPROM contents.
> 	What is the best method of saving some bytes (2) in the internal
> EEPROM and getting them back without corruption? Is there some sort
> of FEC applied to memories?

AT90S2313 micro had been a notorious microcontroller
in terms of its EEPROM data content reliability. Try
new ATtiny2313 micros, they have a real built-in BOD
circuitry. Some of the EEPROM data loss issues come
from non-existence of a BOD circuit.

Hope this helps.

Murat Karadeniz
http://www7.brinkster.com/mukas/



--- Robert Adsett
<subscriptions@aeolusdevelopment.com> wrote:

> At 11:19 PM 9/19/04 -0400, you wrote:
> >At 10:25 PM 9/19/04 -0300, you wrote:
> > >         I have a circuit using an AT90S2313
> working on a very noisy
> > >environment and subject to program 'crashes'
> sometimes.
> > >         The Watchdog is very efficient
> recovering from crashes, but
> > >I'm having a corruption on the EEPROM contents.
> > >         What is the best method of saving some
> bytes (2) in the internal
> > >EEPROM and getting them back without corruption?
> Is there some sort
> > >of FEC applied to memories?
> 
> As promised the reference to the National app-note.
> It's AN482 on error 
> detection and correction.  I've used their
> techniques on external ee in a 
> noisy environment.  These are aimed more at single
> bit wearout type errors 
> though, or single bit data stream corruption.  As a
> final resort detection 
> of corruption it has a use but I think the base
> problems are not addressed 
> by this.  The errors I've seen (and I have to say
> they weren't on internal 
> atmel parts) appeared to be more extensive.  The
> approaches we took were
> 
>   - multiple copies of infrequently changing data
> (such as parameters), 
> with fletcher checksums to detect changes.
>   - Hamming code protection of frequently changing
> data (such as timers)
>   - no protection of error codes
> 
> Even with this protection all copies of the
> parameters would occasionally 
> get corrupted.  Further efforts led to
>   - many code reviews looking for SW failures.  The
> SW would only turn off 
> write protection for the time of the update of
> whatever location was being 
> updated (and of course in the case of multiple
> copies the checksum/crc of 
> the copy being updated would be updated before any
> other copies were modified)
>   - extra decoupling capacitors added to the EE.
> 
> Each of those helped.  Part of the problem at this
> point is the error rate 
> was small.  Only a few units a year.  In some cases
> the parameters would be 
> customized so the default parameters would be the
> ones the customer would 
> use and so any errors that would occur would not
> even be noticed.  Two more 
> things were done though
>   - the PC board was converted to four layers with
> power and ground planes. 
> It appeared from the returns that this probably
> reduced the error rate by a 
> factor of 2.
>   - new designs switched to FRAM from EE.  The write
> time on FRAM is so 
> much faster than the write time for EE (100ns as
> opposed to 5mS) that the 
> window of vulnerability where the device is write
> enabled is very much 
> shorter.  It looked like this was also making a
> difference but I wasn't 
> around long enough to see enough data to be sure.
> 
> Some designs I've seen only write to non-volatile
> storage when the noise is 
> low and they can be sure of power, essentially
> making parameter updates a 
> task that can only take place when the equipment
> isn't running.
> 
> Note that the long write time of the EE means that
> if you write to the EE 
> during normal operation you must be able to detect
> the power failing at 
> least 5mS before you lose power to the micro and EE,
> otherwise you will 
> interrupt in the middle of a write.  None of the EE
> for which I've read the 
> documentation will guarantee what happens when you
> do that and if I recall 
> correctly some of them explicitly warn that doing so
> may corrupt all of the 
> EE contents.
> 
> Robert
> 
> " 'Freedom' has no meaning of itself.  There are
> always restrictions,
> be they legal, genetic, or physical.  If you don't
> believe me, try to
> chew a radio signal. "
> 
>                          Kelvin Throop, III
> 
> 



		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail

I seem to have found a cure for my EEPROM corruption.
	For those who doesn't read my original message, it is not
that EEPROM address zero corruption due to power brown out 
mentioned by ATMEL

	I have a 2313 working on a very noisy environment and subject
to eventual crashes that corrupt the EEPROM. Any address.
	And I'm not allowed to modify the hardware at this time.

	Well, two 'nops' inserted in the EEPROM write routine seem to 
have cured the problem. See below:

		cli
		out	EEARL, address
		out	EEDR, data
		sbi	EECR, EEMWE
		nop					; Inserted
		nop					; Inserted
		sbi	EECR, EEWE
		clr 	address
		out	EEARL, address
		sei

	In fact, I later changed the two 'nops' for a security test
and jump out to avoid spurious EEPROM writes.

	Mark Jordan

On 2 Oct 2004 at 1:49, MuRaT KaRaDeNiZ wrote:

> 
> AT90S2313 micro had been a notorious microcontroller
> in terms of its EEPROM data content reliability. Try
> new ATtiny2313 micros, they have a real built-in BOD
> circuitry. Some of the EEPROM data loss issues come
> from non-existence of a BOD circuit.
> 
> Hope this helps.
> 
> Murat Karadeniz
> http://www7.brinkster.com/mukas/
> 
> 
> 
> --- Robert Adsett
> <subscriptions@aeolusdevelopment.com> wrote:
> 
> > At 11:19 PM 9/19/04 -0400, you wrote:
> > >At 10:25 PM 9/19/04 -0300, you wrote:
> > > >         I have a circuit using an AT90S2313
> > working on a very noisy
> > > >environment and subject to program 'crashes'
> > sometimes.
> > > >         The Watchdog is very efficient
> > recovering from crashes, but
> > > >I'm having a corruption on the EEPROM contents.
> > > >         What is the best method of saving some
> > bytes (2) in the internal
> > > >EEPROM and getting them back without corruption?
> > Is there some sort
> > > >of FEC applied to memories?
> > 
> > As promised the reference to the National app-note.
> > It's AN482 on error 
> > detection and correction.  I've used their
> > techniques on external ee in a 
> > noisy environment.  These are aimed more at single
> > bit wearout type errors 
> > though, or single bit data stream corruption.  As a
> > final resort detection 
> > of corruption it has a use but I think the base
> > problems are not addressed 
> > by this.  The errors I've seen (and I have to say
> > they weren't on internal 
> > atmel parts) appeared to be more extensive.  The
> > approaches we took were
> > 
> >   - multiple copies of infrequently changing data
> > (such as parameters), 
> > with fletcher checksums to detect changes.
> >   - Hamming code protection of frequently changing
> > data (such as timers)
> >   - no protection of error codes
> > 
> > Even with this protection all copies of the
> > parameters would occasionally 
> > get corrupted.  Further efforts led to
> >   - many code reviews looking for SW failures.  The
> > SW would only turn off 
> > write protection for the time of the update of
> > whatever location was being 
> > updated (and of course in the case of multiple
> > copies the checksum/crc of 
> > the copy being updated would be updated before any
> > other copies were modified)
> >   - extra decoupling capacitors added to the EE.
> > 
> > Each of those helped.  Part of the problem at this
> > point is the error rate 
> > was small.  Only a few units a year.  In some cases
> > the parameters would be 
> > customized so the default parameters would be the
> > ones the customer would 
> > use and so any errors that would occur would not
> > even be noticed.  Two more 
> > things were done though
> >   - the PC board was converted to four layers with
> > power and ground planes. 
> > It appeared from the returns that this probably
> > reduced the error rate by a 
> > factor of 2.
> >   - new designs switched to FRAM from EE.  The write
> > time on FRAM is so 
> > much faster than the write time for EE (100ns as
> > opposed to 5mS) that the 
> > window of vulnerability where the device is write
> > enabled is very much 
> > shorter.  It looked like this was also making a
> > difference but I wasn't 
> > around long enough to see enough data to be sure.
> > 
> > Some designs I've seen only write to non-volatile
> > storage when the noise is 
> > low and they can be sure of power, essentially
> > making parameter updates a 
> > task that can only take place when the equipment
> > isn't running.
> > 
> > Note that the long write time of the EE means that
> > if you write to the EE 
> > during normal operation you must be able to detect
> > the power failing at 
> > least 5mS before you lose power to the micro and EE,
> > otherwise you will 
> > interrupt in the middle of a write.  None of the EE
> > for which I've read the 
> > documentation will guarantee what happens when you
> > do that and if I recall 
> > correctly some of them explicitly warn that doing so
> > may corrupt all of the 
> > EE contents.
> > 
> > Robert
> > 
> > " 'Freedom' has no meaning of itself.  There are
> > always restrictions,
> > be they legal, genetic, or physical.  If you don't
> > believe me, try to
> > chew a radio signal. "
> > 
> >                          Kelvin Throop, III
> > 
> > 
> 
> 
> 
> 		
> __________________________________
> Do you Yahoo!?
> New and Improved Yahoo! Mail - Send 10MB messages!
> http://promotions.yahoo.com/new_mail 
> 
> 
> 
>  
> Yahoo! Groups Links
> 
> 
> 
>  
> 
> 
>

>
>        I have a 2313 working on a very noisy environment and subject
>to eventual crashes that corrupt the EEPROM. Any address.
>        And I'm not allowed to modify the hardware at this time.
>
>        Well, two 'nops' inserted in the EEPROM write routine seem to 
>have cured the problem. See below:
>
>                cli
>                out     EEARL, address
>                out     EEDR, data
>                sbi     EECR, EEMWE
>                nop                                     ; Inserted
>                nop                                     ; Inserted
>                sbi     EECR, EEWE
>                clr     address
>                out     EEARL, address
>                sei

Interesting.  I don't see why this would help though.
It doesn't widen the window of opportunity though.
In the overall scheme of things, it would just seem to delay the write a bit.

I don't see you waiting until the write is complete here, is there a possibility you're coming back in for another write before this write is complete?

Here's the routine I use in the larger chips, which includes a few checks that you aren't doing.


;********************************************************************
;Put a single byte in EEPROM, safely per manual, with optiona readback verify
;Call with pointer to EEPROM in X, data in TEMP.
;Increments X, Trashes TEMP2
;********************************************************************
;
Save_EE:

        ;APPARENT EMULATOR BUG IN THE ICE200 REQUIRES THAT
        ;YOU POLL FOR /EEWE AND /EERE BEFORE WRITING, AFTER A READ

        rcall   Timed_Smack             ;In case the loop takes a while
        in      TEMP2,EECR              ;Poll for ready
        andi    TEMP2,3                 ;Both bits must be zero
        brne    Save_EE                 ;Loop till zero

        out     EEARH,XH                ;Point at the current cell
        out     EEARL,XL                ;
        out     EEDR,TEMP               ;Data's ready to be saved
        adiw    XL,1                    ;Increment the address for next call

        ;WARNING: This section cannot be single-stepped in the
        ;emulator due to timing constraints.
        cli                             ;No ints now
        sbi     EECR,2 ;EEMWE           ;Set master write enable=1
        sbi     EECR,1 ;EEWE            ;Set write enable to 1, starts the write
        sei                             ;Ok, now you can bother me.
        ;End of critical section

        ;rjmp   Save_EE_Exit            ;If you don't want readback, then
                                        ;all you have to do is uncomment this line


        ;Now, we have to wait for the write to complete
Save_EE_Verify:
        ldi     TEMP2,Max_EE_Wait       ;Max mS to wait
        sts     EEPROM_Timer,TEMP2      ;
Save_EE_V_Loop:
        rcall   Timed_Smack             ;In case we wait through a WDT
        lds     TEMP2,EEPROM_Timer      ;
        and     TEMP2,TEMP2             ;Is it zero yet?
        breq    Save_EE_Bad2            ;If so, then signal failure >20ms to write

        in      TEMP2,EECR              ;Poll for EECR,EEWE=1 before continuing!
        andi    TEMP2,1 ;EEWE           ;
        brne    Save_EE_V_Loop          ;Potential to loop forever.


        ;Time to read the data
        ;Address is already set, so just read it back
        sbi     EECR,1 ;EERE            ;Set EE Read Enable
        in      TEMP2,EEDR              ;Get the data

        ;If unequal, then signal failure
        cp      TEMP,TEMP2              ;
        brne    Save_EE_Bad             ;

        ;otherwise
        clc                             ;Indicate success
        rjmp    Save_EE_Exit            ;

        ;Redundant code, but it lets me breakpoint and know which way it failed.

Save_EE_Bad:
        sec                             ;Data didn't match
        
Save_EE_Bad2:
        sec                             ;timeout on readback

Save_EE_Exit:
        ldi     TEMP2,$00               ;Point at non-existent location
        out     EEARL,TEMP2             ;when not in active use.
        out     EEARH,TEMP2             ;
        ret                             ;

At 03:49 AM 10/2/2004, MuRaT KaRaDeNiZ wrote:


>AT90S2313 micro had been a notorious microcontroller
>in terms of its EEPROM data content reliability. Try
>new ATtiny2313 micros, they have a real built-in BOD
>circuitry. Some of the EEPROM data loss issues come
>from non-existence of a BOD circuit.

It was always up to YOU to determine wether you had enough power to complete the write, before starting one. 
You have to assure that a reset will not occur during the write, including a WDT reset.

Unfortunately, a lot of folks wrote weak code, and ran it on weak hardware, and it mostly worked..

On 2 Oct 2004 at 8:54, Dave VanHorn wrote:

> 
> I don't see you waiting until the write is complete here, is there a
> possibility you're coming back in for another write before this write is
> complete? 
> 

	I forgot to include that write complete check here, but it does 
exist before the write routine.

	Mark

Hi,

	I'm having a weird problem with a Mega8 running on the 
internal clock oscilator at 1 MHz. The internal Power-on Reset 
seems not to be working. 
	Every time I power up the circuit, I have to manually reset 
the Mega8. The power at the Vcc pin rises from 0 to +5V in 4mS.
The RESET pin has a 22k to +5V and 4.7uF to GND.
	Have tried several fuses combinations but no luck.
	Am I missing something?

	Thanks.
	Mark Jordan

I was using 100nF and tried 4.7uF. No luck. Same behavior.

	Mark

On 23 Oct 2004 at 13:43, Henry Carl Ott wrote:

> 
> That 4.7 uf cap seems a little large to me.
>   I don't know if there is a maximum rise time on the reset signal, but 
> something in the .01 range might be more appropriate.
> 
> -carl
> 
> 
> At 12:25 PM 10/23/2004, you wrote:
> 
> 
> >         Hi,
> >
> >         I'm having a weird problem with a Mega8 running on the
> >internal clock oscilator at 1 MHz. The internal Power-on Reset
> >seems not to be working.
> >         Every time I power up the circuit, I have to manually reset
> >the Mega8. The power at the Vcc pin rises from 0 to +5V in 4mS.
> >The RESET pin has a 22k to +5V and 4.7uF to GND.
> >         Have tried several fuses combinations but no luck.
> >         Am I missing something?
> >
> >         Thanks.
> >         Mark Jordan
> >
> >
> >
> >
> >
> >Yahoo! Groups Links
> >
> >
> >
> >
> 
> 
> 
> 
>  
> Yahoo! Groups Links
> 
> 
> 
>  
> 
> 
>

Sorry guys, It was a Timer initialization problem, nothing 
related to the Power-On Reset.  My bad...

	Thanks for your help!

	Mark Jordan

On 23 Oct 2004 at 11:01, Larry Barello wrote:

> 
> Putting a capacitor and resistor on the reset line is archaic and doesn't do
> anything to improve the performance of the AVR chip.  Period.  It comes from
> the "classic" AVR days - and even then it was useless.  You need a proper
> external reset chip for those processors.  Any of the mega or tiny series
> processors has a built in BOD circuit which (IMHO) renders all the external
> doodads pointless.
> 
> My recommendation: take off the R-C, enable the BOD (that is separate from
> setting the voltage), and set your fuses for the maximum delay (64ms).
> 
> -----Original Message-----
> ...
> >
> >         I'm having a weird problem with a Mega8 running on the
> >internal clock oscilator at 1 MHz. The internal Power-on Reset
> >seems not to be working.
> >         Every time I power up the circuit, I have to manually reset
> >the Mega8. The power at the Vcc pin rises from 0 to +5V in 4mS.
> >The RESET pin has a 22k to +5V and 4.7uF to GND.
> >         Have tried several fuses combinations but no luck.
> >         Am I missing something?
> >
> >         Thanks.
> >         Mark Jordan
> 
> 
> 
> 
> 
> 
> 
>  
> Yahoo! Groups Links
> 
> 
> 
>  
> 
> 
>

That 4.7 uf cap seems a little large to me.
  I don't know if there is a maximum rise time on the reset signal, but 
something in the .01 range might be more appropriate.

-carl


At 12:25 PM 10/23/2004, you wrote:

>         Hi,
>
>         I'm having a weird problem with a Mega8 running on the
>internal clock oscilator at 1 MHz. The internal Power-on Reset
>seems not to be working.
>         Every time I power up the circuit, I have to manually reset
>the Mega8. The power at the Vcc pin rises from 0 to +5V in 4mS.
>The RESET pin has a 22k to +5V and 4.7uF to GND.
>         Have tried several fuses combinations but no luck.
>         Am I missing something?
>
>         Thanks.
>         Mark Jordan
>
>
>
>
>
>Yahoo! Groups Links
>
>
>
>

Putting a capacitor and resistor on the reset line is archaic and doesn't do
anything to improve the performance of the AVR chip.  Period.  It comes from
the "classic" AVR days - and even then it was useless.  You need a proper
external reset chip for those processors.  Any of the mega or tiny series
processors has a built in BOD circuit which (IMHO) renders all the external
doodads pointless.

My recommendation: take off the R-C, enable the BOD (that is separate from
setting the voltage), and set your fuses for the maximum delay (64ms).

-----Original Message-----
...

>
>         I'm having a weird problem with a Mega8 running on the
>internal clock oscilator at 1 MHz. The internal Power-on Reset
>seems not to be working.
>         Every time I power up the circuit, I have to manually reset
>the Mega8. The power at the Vcc pin rises from 0 to +5V in 4mS.
>The RESET pin has a 22k to +5V and 4.7uF to GND.
>         Have tried several fuses combinations but no luck.
>         Am I missing something?
>
>         Thanks.
>         Mark Jordan

As Larry remarked, caps (for noise immunity) don't do much on the newer 
chips. The 4.7uf just seemed very large to me.

  Time to check power supply, & as always, check fuses.

-carl


At 01:02 PM 10/23/2004, you wrote:

>         I was using 100nF and tried 4.7uF. No luck. Same behavior.
>
>         Mark
>
>On 23 Oct 2004 at 13:43, Henry Carl Ott wrote:
>
> >
> > That 4.7 uf cap seems a little large to me.
> >   I don't know if there is a maximum rise time on the reset signal, but
> > something in the .01 range might be more appropriate.
> >
> > -carl
> >
> >
> > At 12:25 PM 10/23/2004, you wrote:
> >
> >
> > >         Hi,
> > >
> > >         I'm having a weird problem with a Mega8 running on the
> > >internal clock oscilator at 1 MHz. The internal Power-on Reset
> > >seems not to be working.
> > >         Every time I power up the circuit, I have to manually reset
> > >the Mega8. The power at the Vcc pin rises from 0 to +5V in 4mS.
> > >The RESET pin has a 22k to +5V and 4.7uF to GND.
> > >         Have tried several fuses combinations but no luck.
> > >         Am I missing something?
> > >
> > >         Thanks.
> > >         Mark Jordan
> > >
> > >
> > >
> > >
> > >
> > >Yahoo! Groups Links
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
> >
> >
>
>
>
>
>
>
>Yahoo! Groups Links
>
>
>
>

Hi,

I'm trying AVRx for the first time and have run into
some difficulties I don't know how to resolve.

Using the latest version of WinAVR (3.4.1) and the
latest version of AVRx (2.6e), I get the following
errors from a clean install, 'make clean' and 'make
gcc':

===========================
C:\PROGRA~1\WINAVR\UTILS\BIN\MAKE.EXE: *** No rule to
make target `avrx_generatesinglestepinterrupt.o',
needed by `avrx.a'.  Stop.
===========================

Being new to all this, I'm not quite sure what Make is
trying to tell me.

Jeff Engel

=====
Happiness is - positive intake manifold pressure.


		
_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com

You should direct this question to the AvrX mailing list at Yahoogroups.

Have you defined the AVRX environment variable?  It points to the directory
that contains avrx/Examples/TestCases

The error message is Make telling you that it needs to build
avrx_generatesinglestep.o, but doesn't know how.  That could be either that
the source file is missing, or the rule telling it how to turn .s into .o is
missing.  Neither seems likely...

2.6e is pretty old (not that there is anything newer) so there might be
issues with the version of make with WinAVR, but it seems to build Ok on my
machine with 3.3.1

-----Original Message-----
From: Jeffrey Engel [mailto:jengeltx@yahoo.com]
Sent: Saturday, October 23, 2004 1:23 PM
To: AVR-Chat@yahoogroups.com
Subject: [AVR-Chat] Newby questions



Hi,

I'm trying AVRx for the first time and have run into
some difficulties I don't know how to resolve.

Using the latest version of WinAVR (3.4.1) and the
latest version of AVRx (2.6e), I get the following
errors from a clean install, 'make clean' and 'make
gcc':

===========================
C:\PROGRA~1\WINAVR\UTILS\BIN\MAKE.EXE: *** No rule to
make target `avrx_generatesinglestepinterrupt.o',
needed by `avrx.a'.  Stop.
===========================

Being new to all this, I'm not quite sure what Make is
trying to tell me.

Jeff Engel

=====
Happiness is - positive intake manifold pressure.



_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com




Yahoo! Groups Links

Thanks!

Initially, I did forget the AVRX environmental
variable, but it's now correct.

Jeff Engel
--- Larry Barello <yahoo@barello.net> wrote:

> 
> You should direct this question to the AvrX mailing
> list at Yahoogroups.
> 
> Have you defined the AVRX environment variable?  It
> points to the directory
> that contains avrx/Examples/TestCases
> 


=====
Happiness is - positive intake manifold pressure.


		
_______________________________
Do you Yahoo!?
Express yourself with Y! Messenger! Free. Download now. 
http://messenger.yahoo.com