Losing EEPROM value after a few days

Log in or register to post comments
Go To Last Post
32 posts / 0 new
Author
Message
kk6gm
kk6gm's picture
Level: Raving Lunatic
Joined: Fri. Sep 11, 2009
Posts: 4013 View posts
Location: Sacramento, CA
#1
Posted by kk6gm: Wed. Sep 30, 2009 - 05:56 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This one is so weird I assume I'm doing something wrong (in large part because I haven't worked with eeprom on the AVR before).

I've got a couple of configuration values in eeprom (ATmega48P), and after a day or two unpowered many units have lost the values. At this point my code does not write to eeprom, only reads from it. I write the eeprom by downloading the .eep file from AVR Studio.

Here are the relevant code snips:

Initializing in source:

uint8_t	EEMEM EE_device_addr = 3;

Reading back on code startup:

Device_addr = eeprom_read_byte( &EE_device_addr );

From the map file:

.eeprom         0x00810000        0x2
 *(.eeprom*)
 .eeprom        0x00810000        0x2 globals.o
                0x00810001                EE_frame_cnt
                0x00810000                EE_device_addr
                0x00810002                __eeprom_end = .

The code compiles without error or warning, and it always runs correctly after I program the devices. It's only when I turn on the units a few days later that some have lost their configuration values, replaced with random values such as 0x1D, 0xEE, 0xFC, 0xFF.

FWIW, of the two configuration values I'm setting, the first is always trashed when I read back from bad units, while the second was only trashed in one unit.

Any ideas?

Mike

Tags:

AVR Microcontrollers, megaAVR and tinyAVR, ATmega48, ATmega48P, AVR040, atmega328pb
Top
rstahlhu
rstahlhu's picture
Level: Posting Freak
Joined: Sat. Jun 8, 2002
Posts: 1234 View posts
Location: Champaign, IL USA
Posted by rstahlhu: Wed. Sep 30, 2009 - 06:03 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Do you have the BOD enabled? If not, enable it and see if it helps.

Top
ka7ehk
ka7ehk's picture
Level: 10k+ Postman
Joined: Fri. Nov 22, 2002
Posts: 22597 View posts
Location: Tangent, OR, USA
Posted by ka7ehk: Wed. Sep 30, 2009 - 06:04 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Do you have the BOD turned on?

If you check one of these units that is prone to EEPROM data loss after a shorter off time (a few hours, 12 hours, a day, etc), what do you find?

Address 0x0000 has had historic problems, as recall. This was, I think, largely solved by using the BOD. But, many still do not write anything to that address.

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

Top
Bronze Markbobgardner
bobgardner's picture
Level: 10k+ Postman
Joined: Wed. Sep 4, 2002
Posts: 26609 View posts
Location: Orlando Florida
Posted by bobgardner: Wed. Sep 30, 2009 - 06:17 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Are you using a bootloader? Maybe you get a power glitch and the bootloader erases flash, and sits there waiting for the new program to start coming down the wire?

Imagecraft compiler user

Top
yellowboy_75
yellowboy_75's picture
Level: Hangaround
Joined: Wed. May 3, 2006
Posts: 259 View posts
Location: India
Posted by yellowboy_75: Wed. Sep 30, 2009 - 07:26 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Not only 0x00 address, but without BOD, most of the eeprom gets washed out.

http://richduino.com
http://EmbeddedMarket.com

Top
kk6gm
kk6gm's picture
Level: Raving Lunatic
Joined: Fri. Sep 11, 2009
Posts: 4013 View posts
Location: Sacramento, CA
Posted by kk6gm: Wed. Sep 30, 2009 - 08:43 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This is very interesting. So without BOD enabled, eeprom that has been correctly written may be corrupted later? What is the mechanism for this? Maybe I should ask, how can Atmel sell such devices?

FWIW, I'm using a 6A supply for Vcc, and probably not drawing more than 200mA worst case. But I'm going to read up on BOD and eeprom for sure.

Mike

Top
glitch
glitch's picture
Level: Raving Lunatic
Joined: Sat. Jan 12, 2002
Posts: 8620 View posts
Location: Canada
Posted by glitch: Wed. Sep 30, 2009 - 09:01 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

yellowboy_75 wrote:
Not only 0x00 address, but without BOD, most of the eeprom gets washed out.

Not quite true. Not having BOD disabled does not corrupt the EEPROM directly, or more of it. Having said that, any byte in EEPROM is equally susceptible to corruption, not just address 0. Enabling the BOD prevents your code from mis-executing, as a result of a brown-out condition, thus causing the corruption. The corrupted byte[s] will be a result of whatever is currently in the EEPROM address register when the brown-out occurs.

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

Top
alwelch
alwelch's picture
Level: Resident
Joined: Wed. May 1, 2002
Posts: 845 View posts
Location: Texas
Posted by alwelch: Wed. Sep 30, 2009 - 11:25 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Below is what CodeVisionAVR support suggest regarding eeprom data problems...

"You don't need to take any precautions on EEPROM access when using CVAVR.
However you must use these techniques:
- proper power supply
- external reset supervisor IC
- when storing important data in EEPROM, store the same value in 3 different variables.
When reading the data, read all 3 variables and compare their values.
If one of the values doesn't match the other two, re-write it with the correct value read from the other two.

This will most likely solve your problems.

"

Top
ka7ehk
ka7ehk's picture
Level: 10k+ Postman
Joined: Fri. Nov 22, 2002
Posts: 22597 View posts
Location: Tangent, OR, USA
Posted by ka7ehk: Wed. Sep 30, 2009 - 11:32 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ahh, the old "majority must be right" proposition! But, in the case of an EEPROM subject to "corruption", it can get you a long ways.

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

Top
alwelch
alwelch's picture
Level: Resident
Joined: Wed. May 1, 2002
Posts: 845 View posts
Location: Texas
Posted by alwelch: Wed. Sep 30, 2009 - 11:35 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yea, Jim but the part about the reset supervisor may be the key. I use one on my AVR boards and also depend on EEPROM data and very rarely have a problem. I can see where if things are real bad even three variables for the same value will not help.

Top
tkurowski
tkurowski's picture
Level: Hangaround
Joined: Tue. Feb 10, 2009
Posts: 383 View posts
Posted by tkurowski: Thu. Oct 1, 2009 - 05:49 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Simply enabling BOD eliminates many problems?
Would there be a problem for example if you read EEPROM into a variable at startup without BOD, then never again? Or is it mostly when you get flickering power when your code is running and youre constantly reading from eeprom?

Top
kk6gm
kk6gm's picture
Level: Raving Lunatic
Joined: Fri. Sep 11, 2009
Posts: 4013 View posts
Location: Sacramento, CA
Posted by kk6gm: Thu. Oct 1, 2009 - 06:46 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

tkurowski wrote:
Simply enabling BOD eliminates many problems?
Would there be a problem for example if you read EEPROM into a variable at startup without BOD, then never again? Or is it mostly when you get flickering power when your code is running and youre constantly reading from eeprom?

My situation is the former, I read the values once at startup and never again, and I've got what should be solid voltage to the boards. But I've never actually looked at the turn-on waveform of this power supply, which I should do next.

Mike

Top
glitch
glitch's picture
Level: Raving Lunatic
Joined: Sat. Jan 12, 2002
Posts: 8620 View posts
Location: Canada
Posted by glitch: Thu. Oct 1, 2009 - 06:55 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

tkurowski wrote:
Simply enabling BOD eliminates many problems?
Would there be a problem for example if you read EEPROM into a variable at startup without BOD, then never again? Or is it mostly when you get flickering power when your code is running and youre constantly reading from eeprom?

Problem is, that when there is a brown-out condition, the CPU can do ANYTHING. Bit's in the CPU's register will change at random, so the end result is a random operation, or set of operations. Bottom line, always use a brown-out detector. Either the internal one, or an external one.

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

Top
theatrus
theatrus's picture
Level: Wannabe
Joined: Wed. Jan 16, 2002
Posts: 64 View posts
Location: California
Posted by theatrus: Thu. Oct 1, 2009 - 07:40 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I agree, I have had some very curious things happen to processors operating at brownout conditions. In one particular instance, an MSP430 managed to rewrite flash, which is very hard to do (there is a lockout magic-key register you need to write a valid value to in order to run the peripheral).

StackFoundry (AVR32, Open Source Hardware) | Blog

Top
leon_heller
leon_heller's picture
Level: Raving Lunatic
Joined: Fri. Jul 27, 2001
Posts: 7672 View posts
Location: St. Leonards-on-Sea (UK)
Posted by leon_heller: Thu. Oct 1, 2009 - 07:49 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I was very puzzled once when a CPLD on a board I was developing randomly stopped working. I eventually twigged that turning my PC on and off with the programming cable attached to the board was waggling the pins on the parallel port I was using for programming, and corrupting the CPLD memory. That sort of thing is unlikely with the current USB interfaces.

Leon Heller G1HSM

Top
danni
danni's picture
Level: Raving Lunatic
Joined: Wed. Sep 5, 2001
Posts: 2960 View posts
Posted by danni: Thu. Oct 1, 2009 - 07:53 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you want to use the EEPROM, you must enable the brownout reset or connect a proper working undervoltage reset circuit. :!:

Furthermore, if a crystal was used, you must always set the maximum reset delay.
A crystal may need up to 50ms to oscillate stable. :!:

Peter

Top
tkurowski
tkurowski's picture
Level: Hangaround
Joined: Tue. Feb 10, 2009
Posts: 383 View posts
Posted by tkurowski: Thu. Oct 1, 2009 - 01:43 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thats awesome. Good to know that I've randomly been doing all the right things :D

Top
joeyAVR
joeyAVR's picture
Level: Hangaround
Joined: Wed. Aug 6, 2008
Posts: 365 View posts
Location: Rockall
Posted by joeyAVR: Thu. Oct 1, 2009 - 01:59 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My early projects kept suffering from EEPROM corruption on startup, despite following the extensive advice from Atmel. A clean on-off switch and a decent size cap across the supply help too.

Since they added the BOD functions and the timeout on writing EEPROM, things seem to be OK.

I think that some individual ICs are more susceptible than others too!.

Cheers,

Joey

Top
kk6gm
kk6gm's picture
Level: Raving Lunatic
Joined: Fri. Sep 11, 2009
Posts: 4013 View posts
Location: Sacramento, CA
Posted by kk6gm: Fri. Oct 2, 2009 - 01:02 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

OK, I enabled BOD and the problem seems to have gone away. Where before I could kill a unit with just a few power cycles, now I couldn't kill any of 8 units with a few dozen cycles. The power supply turn-on/turn-off wasn't dirty, but it did have an exponential waveform.

So, lesson learned. EEPROM is very fragile. At least in the AVR.

Mike

Top
Bronze Marktheusch
theusch's picture
Level: 10k+ Postman
Joined: Mon. Feb 19, 2001
Posts: 40422 View posts
Location: Wisconsin USA
Posted by theusch: Fri. Oct 2, 2009 - 01:43 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

EEPROM is very fragile. At least in the AVR.

No, it isn't.

When supply power is dropping, there is almost always a ramp down. Steep or shallow, it doesn't make much difference. Take a time slice of that ramp say every millisecond. Note that your AVR may be rated to, say, 2V Vcc min.

During each of those slices, the AVR executes many instructions. As you get to the 2V level, everything is still traveling along nicely.

Once you get below the rated min supply voltage, at some point pieces of the AVR are going to give up and not run properly. I cannot tell you which subsystem will fail, and at exactly what supply voltage level.

We can tell you that on e of the common symptoms is that an EEPROM write is triggered. And that is to the EEAR address. If EEAR "dies" to 0 first, then address 0 of EEPROM will be wiped out. If not, it will be whatever address EEAR is pointing to.

Other subsystems may also exhibit "faulty" operation when run below spec. The EEPROM is noticeable because the evidence is left behind. One could probably construct a scenario with different legs of a transistor bridge on different AVR I/O ports and one dies before the other, causing a short in the bridge. Does that mean the AVR's I/O ports are "fragile"?

The BOD is there to prevent the microcontroller from >>attempting<< to run when in an out-of-spec situation. Use it--AFAIK every AVR model has one, and it works fine. So it costs nothing. As mentioned above, we all had external devices for that function on our production designs before the internal BOD became commonplace. (Mega8? CRS)

I've always felt that the byte-writable EEPROM on the AVR is one of the nicer features.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

Top
Gold Markclawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 103883 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Fri. Oct 2, 2009 - 02:02 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Lee,

I guess there's an argument to say that BOD should be enabled by default as it doesn't make much sense for it not to be used.

Unfortunately there's an even stronger argument that Atmel cannot guess what your planned Vcc is going to be so sadly they cannot make it the default.

Maybe the datasheets should at least start with something like "Warning: for correct operation the AVR should have BOD enabled, once you have determined Vcc pick the right BOD level and enable it" ?

(I suppose there is the power consideration of using BOD too?)

Cliff

Top
kk6gm
kk6gm's picture
Level: Raving Lunatic
Joined: Fri. Sep 11, 2009
Posts: 4013 View posts
Location: Sacramento, CA
Posted by kk6gm: Fri. Oct 2, 2009 - 02:10 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:
Quote:

EEPROM is very fragile. At least in the AVR.

No, it isn't.

Well look at it this way. AVR flash doesn't seem to corrupt on power down. AVR EEPROM does, even when there is no code in the program that writes to EEPROM. I'd call that a problem. But as you note, there is a free and easy solution, and I can live with that.

Mike

Top
dak664
dak664's picture
Level: Raving Lunatic
Joined: Sun. Jun 15, 2008
Posts: 2118 View posts
Location: North Carolina USA
Posted by dak664: Fri. Oct 2, 2009 - 02:38 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I switched the ADC calibration from flash into EEPROM based on this forum which suggested low-voltage reads were OK as long as no writes were attempted! I don't want to enable the BOD as that is a continuous 50ua load on the battery. Well, I know what to look for and if I have problems can always switch back to flash.

Top
tkurowski
tkurowski's picture
Level: Hangaround
Joined: Tue. Feb 10, 2009
Posts: 383 View posts
Posted by tkurowski: Fri. Oct 2, 2009 - 02:50 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I always thought the inherent brown out levels were dumb on the fuses.
One is 4.3V, and the next is 2.7V on my avr.
I tested my particular AVR and found it operated down to 3.1V. I don't like that I need an external BOD for a ~3.5V brown out, cus 4.3 is too high in my application (don't want it to reset too early due to external components drawing a lot of current when starting to move (actuators)), and 2.8 is dangerously too low.

Top
Bronze Marktheusch
theusch's picture
Level: 10k+ Postman
Joined: Mon. Feb 19, 2001
Posts: 40422 View posts
Location: Wisconsin USA
Posted by theusch: Fri. Oct 2, 2009 - 03:02 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I don't want to enable the BOD as that is a continuous 50ua load on the battery.

That is certainly a consideration. Atmel has addressed this to some extent (large extent?) with the "sleeping BOD". (Is that on all P chips?)

Quote:

I always thought the inherent brown out levels were dumb on the fuses.
One is 4.3V, and the next is 2.7V on my avr.

That is indeed a "trap". The levels are fairly convenient for a 5V and 3.3V app.

==============
But if levels are inconvenient, you should add an external device that fits your needs. Don't enter there unsheathed without proper protection. ;)

[Do you really have dips in the regulated Vcc? Scary.]

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

Top
williambarbosalima
williambarbosalima's picture
Level: New Member
Joined: Wed. May 22, 2013
Posts: 2 View posts
Posted by williambarbosalima: Fri. May 12, 2017 - 08:06 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

I was having the same problem, fois resolved with the answers contained above ... I have several positions of the eeprom being always recorded to eeprom in position 0x0000 I lost the data, soon I stopped using the position 0x0000, I also decided to activate BOB, it was already active.

Top
Bronze Markjs
js's picture
Level: Moderator
Joined: Wed. Mar 28, 2001
Posts: 30950 View posts
Location: Sydney, Australia (Gum trees, Koalas and Kangaroos, No Edelweis, but plenty of Corona beer)
Posted by js: Fri. May 12, 2017 - 09:37 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It's an 8 YO thread, but the EEPROM being erased randomly at 0x0000 is old known fact and most people don't use it particularly with older chips.

John Samperi

Ampertronics Pty. Ltd.

https://www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

Top
Bronze Marktheusch
theusch's picture
Level: 10k+ Postman
Joined: Mon. Feb 19, 2001
Posts: 40422 View posts
Location: Wisconsin USA
Posted by theusch: Fri. May 12, 2017 - 10:16 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

js wrote:
It's an 8 YO thread, but the EEPROM being erased randomly at 0x0000 is old known fact ...

 

"known fact", and tribal knowledge, and similar?  I'll agree.

 

Randomly?!?  Not so much.  There is nothing random about it.  Without an appropriate BOD enabled (and I'd really like to explore the claim in #26 that it in fact was/is enabled at an appropriate value), and the supplyV drops below a safe level, and with no BOD the AVR keeps trying like a steer, and one of the things that happens is that the EEAR register(s) cannot hold their value, and then an EEPROM erase/write operation is carried out at address 0 instead.

 

 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

Top
Bronze MarkJohanEkdahl
JohanEkdahl's picture
Level: 10k+ Postman
Joined: Wed. Mar 27, 2002
Posts: 26945 View posts
Location: Lund, Sweden
Posted by JohanEkdahl: Sat. May 13, 2017 - 03:35 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

All OT, so ignore at will:

williambarbosalima wrote:
I also decided to activate BOB

1. StarTrek in the AVR quadrant: "Please state the nature of your EEPROM emergency.." (cf. https://www.youtube.com/watch?v=... )

2. Been a while since we've seen him, hasn't it..

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here. 

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

Last Edited: Sat. May 13, 2017 - 03:41 PM
Top
JegerKev7
JegerKev7's picture
Level: New Member
Joined: Fri. Dec 2, 2016
Posts: 10 View posts
Posted by JegerKev7: Fri. Jan 14, 2022 - 12:49 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Thought I'd chime in here. I had released a product years ago when I was just starting playing with MCUs for commercial products, that wrote a preset number for a music product to start up on (and show on a seven segment display) in the EEPROM on a 328P. It seemed to work fine, I never experienced an issue. We put it out in production and later units were freezing at random with the seven-segment display. They were locked up and the whole program wouldn't work.

 

Turns out because I didn't have the BOD enabled when I was reading from EEPROM on startup to determine which preset to show on the display, something got corrupted and caused my program to be stuck in a weird state (I still don't know today exactly what was going on). I never caught it during my tests.

 

It would happen if I removed the power supply and plugged it back in quickly within about 10-20 times. Had to get over 100 units back and re-program them as I had no bootloader or remote way for the customer to do it. It was a decently heavy product too.

 

Once I enabled the BOD, the whole issue went away. I learned the REAL hard way on that one... 

 

I eventually found an Atmel video on youtube about the BOD and them mentioning something about the EEPROM needing it. Looking at the datasheet online today (I don't know if there was there back then and I missed it) but there is a "Preventing EEPROM Corruption" section 8.4.2 "During periods of low VCC, the EEPROM data can be corrupted because the supply voltage is too low for the
CPU and the EEPROM to operate properly."

 

I was pretty upset back then I never heard of it. Made me paranoid that some other weird issue could happen

Top
gchapman
gchapman's picture
Level: 10k+ Postman
Joined: Tue. Jan 9, 2007
Posts: 15649 View posts
Location: Clay County, Texas, u.S.A.
Posted by gchapman: Fri. Jan 14, 2022 - 02:13 AM (Reply to #30)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JegerKev7 wrote:
... there is a "Preventing EEPROM Corruption" section ...
Preventing EEPROM Corruption | ATmega328PB

JegerKev7 wrote:
Made me paranoid that some other weird issue could happen
Reason can replace paranoiawink

ESD is common with a wide spread of energy (glitch to destruction)

AVR-specific Solutions | AVR040: EMC Design Considerations

...

In fact, the embedded low-cost solutions such as the BOD and internal pullups will do the trick in many designs.

...

 

P.S.

JegerKev7 wrote:
It would happen if I removed the power supply and plugged it back in quickly within about 10-20 times. 
Glitching VCC is one way to anomaly an AVR (excessive dVCC/dt)

Residual Power in Decoupling Capacitors | 8-bit PIC® and AVR® MCU Design and Troubleshooting Checklist

Symptoms:

  • Unusual behavior after power cycling
  • Failure to restart after applying power (appears as failure to start up)

Troubleshooting:

  • Verify that MCLR and RESET are asserted (voltage falls below the threshold)

...

There are a few possible approaches to solve this problem:

...

Bleed residual energy from the system

...

 

"Dare to be naïve." - Buckminster Fuller

Top
Gold Markclawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 103883 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Fri. Jan 14, 2022 - 10:12 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

JegerKev7 wrote:
(I don't know if there was there back then and I missed it) 
That section is in datasheets for devices that even pre-date the release of the 328P so, yeah, I think you can be pretty sure it was right there from the start.

Top