Here's a warning that may hopefully save someone else all the hassle we've just had after migrating a product to the Mega8515 - there may be a similar issue with other back-compatible mega parts.. We had some code that was originally written for a 90S4414. This moved to a 90S8515 a while ago when the 4414 went obsolete. We recently changed to the AtMega8515, again due to the old part going obsolete. We then started seeing apparently random eeprom corruption on some units. We could write and verify the eeprom, but after powering off for an hour the data would sometimes be all FFs, and sometimes correct..... After many false leads and much headscratching, I chanced on a subtle difference between the ATMega8515 and the old 90S4414/8515 parts, which is not highlighted in the datasheet ' differences' section (I have emailed Atmel to suggest they add it..). On the Mega version, The EEADR registers are not initialised to a guaranteed state on reset. They are initialised to 0 on the old 90S parts. As the code was originally for the 4414, (which has 256 bytes eeprom, hence no EEADRH), and then moved with no problems to the 90S8515 (which initilises EEADRH to 0), there was no code to explicitly clear EEADRH, so on the Mega8515, we had what amounted to a 'random page swap' on power-up, and some rather unhappy customers...
Warning on migrating to ATMega8515 - eeprom problem
Started by ●November 1, 2004
Reply by ●November 1, 20042004-11-01
"Mike Harrison" <mike@whitewing.co.uk> wrote in message news:k04co054e0g5rcbn50h2tptfh3i3sg46r8@4ax.com...> Here's a warning that may hopefully save someone else all the hassle we'vejust had after migrating> a product to the Mega8515 - there may be a similar issue with otherback-compatible mega parts..>Another good thing on the Mega8515 is to enable the brown-out detection. Failing to do so can also lead to eeprom corruption during startup on too slow rising power supplies. Meindert
Reply by ●November 1, 20042004-11-01
In article <k04co054e0g5rcbn50h2tptfh3i3sg46r8@4ax.com>, Mike Harrison <mike@whitewing.co.uk> writes>Here's a warning that may hopefully save someone else all the hassle >we've just had after migrating >a product to the Mega8515 - there may be a similar issue with other >back-compatible mega parts.. > >We had some code that was originally written for a 90S4414. This moved >to a 90S8515 a while ago when >the 4414 went obsolete. We recently changed to the AtMega8515, again >due to the old part going >obsolete. >We then started seeing apparently random eeprom corruption on some >units. We could write and verify >the eeprom, but after powering off for an hour the data would sometimes >be all FFs, and sometimes >correct..... > >After many false leads and much headscratching, I chanced on a subtle >difference between the >ATMega8515 and the old 90S4414/8515 parts, which is not highlighted in >the datasheet ' differences' >section (I have emailed Atmel to suggest they add it..). > >On the Mega version, The EEADR registers are not initialised to a >guaranteed state on reset. They >are initialised to 0 on the old 90S parts. As the code was originally >for the 4414, (which has 256 >bytes eeprom, hence no EEADRH), and then moved with no problems to the >90S8515 (which initilises >EEADRH to 0), there was no code to explicitly clear EEADRH, so on the >Mega8515, we had what amounted >to a 'random page swap' on power-up, and some rather unhappy customers...I believe this is the (undocumented) case with all registers on all AVR Mega parts - the registers all power up in an undefined state, but as you say on the older AVRs they power up consistently at 0. Has caused some fun when porting code over. -- Tim Mitchell
Reply by ●November 1, 20042004-11-01
"Tim Mitchell" <timng@sabretechnology.co.uk> skrev i meddelandet news:H8LIWLibzjhBFAV2@tega.co.uk...> In article <k04co054e0g5rcbn50h2tptfh3i3sg46r8@4ax.com>, Mike Harrison > <mike@whitewing.co.uk> writes > >Here's a warning that may hopefully save someone else all the hassle > >we've just had after migrating > >a product to the Mega8515 - there may be a similar issue with other > >back-compatible mega parts.. > > > >We had some code that was originally written for a 90S4414. This moved > >to a 90S8515 a while ago when > >the 4414 went obsolete. We recently changed to the AtMega8515, again > >due to the old part going > >obsolete. > >We then started seeing apparently random eeprom corruption on some > >units. We could write and verify > >the eeprom, but after powering off for an hour the data would sometimes > >be all FFs, and sometimes > >correct..... > > > >After many false leads and much headscratching, I chanced on a subtle > >difference between the > >ATMega8515 and the old 90S4414/8515 parts, which is not highlighted in > >the datasheet ' differences' > >section (I have emailed Atmel to suggest they add it..). > > > >On the Mega version, The EEADR registers are not initialised to a > >guaranteed state on reset. They > >are initialised to 0 on the old 90S parts. As the code was originally > >for the 4414, (which has 256 > >bytes eeprom, hence no EEADRH), and then moved with no problems to the > >90S8515 (which initilises > >EEADRH to 0), there was no code to explicitly clear EEADRH, so on the > >Mega8515, we had what amounted > >to a 'random page swap' on power-up, and some rather unhappy customers... > > I believe this is the (undocumented) case with all registers on all AVR > Mega parts - the registers all power up in an undefined state, but as > you say on the older AVRs they power up consistently at 0. Has caused > some fun when porting code over. > -- > Tim MitchellThanks, I spread it around internally ! However, I think you need to read the datasheet more carefully. Most register have a defined state at reset, but the EEAR does not. -- Best Regards, Ulf Samuelsson ulf@a-t-m-e-l.com This is a personal view which may or may not be share by my Employer Atmel Nordic AB
Reply by ●November 1, 20042004-11-01
One thing I can't understand about the previous and the latest AVRs: Why the EEPROM write takes about 1ms on the "old" AVRs and about 8ms on the "new" AVRs? The funny thing is that ATMega128 has the EEPROM write time of 8ms in the native mode and 1ms in ATMega103 compatibility mode! So the different silicon is apparently not an issue. The difference in EEPROM timing caused us a problem when porting the code from ATMega323 to ATMega32. Vladimir Vassilevsky DSP and Mixed Signal Design Consultant http://www.abvolt.com Mike Harrison wrote:> Here's a warning that may hopefully save someone else all the hassle we've just had after migrating > a product to the Mega8515 - there may be a similar issue with other back-compatible mega parts.. > > We had some code that was originally written for a 90S4414. This moved to a 90S8515 a while ago when > the 4414 went obsolete. We recently changed to the AtMega8515, again due to the old part going > obsolete. > We then started seeing apparently random eeprom corruption on some units. We could write and verify > the eeprom, but after powering off for an hour the data would sometimes be all FFs, and sometimes > correct..... > > After many false leads and much headscratching, I chanced on a subtle difference between the > ATMega8515 and the old 90S4414/8515 parts, which is not highlighted in the datasheet ' differences' > section (I have emailed Atmel to suggest they add it..). > > On the Mega version, The EEADR registers are not initialised to a guaranteed state on reset. They > are initialised to 0 on the old 90S parts. As the code was originally for the 4414, (which has 256 > bytes eeprom, hence no EEADRH), and then moved with no problems to the 90S8515 (which initilises > EEADRH to 0), there was no code to explicitly clear EEADRH, so on the Mega8515, we had what amounted > to a 'random page swap' on power-up, and some rather unhappy customers...
Reply by ●November 1, 20042004-11-01
On Mon, 1 Nov 2004 20:29:08 +0100, "Ulf Samuelsson" <ulf@atmel.nospam.com> wrote:> >"Tim Mitchell" <timng@sabretechnology.co.uk> skrev i meddelandet >news:H8LIWLibzjhBFAV2@tega.co.uk... >> In article <k04co054e0g5rcbn50h2tptfh3i3sg46r8@4ax.com>, Mike Harrison >> <mike@whitewing.co.uk> writes >> >Here's a warning that may hopefully save someone else all the hassle >> >we've just had after migrating >> >a product to the Mega8515 - there may be a similar issue with other >> >back-compatible mega parts.. >> > >> >We had some code that was originally written for a 90S4414. This moved >> >to a 90S8515 a while ago when >> >the 4414 went obsolete. We recently changed to the AtMega8515, again >> >due to the old part going >> >obsolete. >> >We then started seeing apparently random eeprom corruption on some >> >units. We could write and verify >> >the eeprom, but after powering off for an hour the data would sometimes >> >be all FFs, and sometimes >> >correct..... >> > >> >After many false leads and much headscratching, I chanced on a subtle >> >difference between the >> >ATMega8515 and the old 90S4414/8515 parts, which is not highlighted in >> >the datasheet ' differences' >> >section (I have emailed Atmel to suggest they add it..). >> > >> >On the Mega version, The EEADR registers are not initialised to a >> >guaranteed state on reset. They >> >are initialised to 0 on the old 90S parts. As the code was originally >> >for the 4414, (which has 256 >> >bytes eeprom, hence no EEADRH), and then moved with no problems to the >> >90S8515 (which initilises >> >EEADRH to 0), there was no code to explicitly clear EEADRH, so on the >> >Mega8515, we had what amounted >> >to a 'random page swap' on power-up, and some rather unhappy customers... >> >> I believe this is the (undocumented) case with all registers on all AVR >> Mega parts - the registers all power up in an undefined state, but as >> you say on the older AVRs they power up consistently at 0. Has caused >> some fun when porting code over. >> -- >> Tim Mitchell > >Thanks, I spread it around internally ! >However, I think you need to read the datasheet more carefully.I don't dispute that the information is in there, but I don't think anyone would think it reasonable to read through a 255 page datasheet line-by-line to compare minor details to spot changes from a part that is promoted as a direct replacement. The datasheet should have a section that itemises EVERY difference, however subtle, so any potential problem areas can easily be looked at. The problem actually 'occurred' a few years ago when we were forced to migrate from the 4414 to the 90S8515 when the 4414 was obsolete, then only manifested itself when we again were forced to change to a new part due to the 8515 going obsolete. Most of us are too busy developing new products to spend a lot of time re-examining code written years ago that breaks when put on a new, supposedly 'compatible' part.....
Reply by ●November 1, 20042004-11-01
"Vladimir Vassilevsky" <antispam_bogus@hotmail.com> skrev i meddelandet news:W%whd.4189$fC4.1110@newssvr11.news.prodigy.com...> One thing I can't understand about the previous and the latest AVRs: > > Why the EEPROM write takes about 1ms on the "old" AVRs and about 8ms on > the "new" AVRs? >> The funny thing is that ATMega128 has the EEPROM write time of 8ms in > the native mode and 1ms in ATMega103 compatibility mode! So the > different silicon is apparently not an issue.That is indeed funny! Here is my guess. IIRC, there was a problem initially with Silicon fabbed in the North Tyneside facility. The part will complete the EEPROM write after a certtain number of cycles of an R/C oscillator. The number of counts is fixed, and set to handle the slow EEPROM. Now we may have a faster EEPROM, but the part does not understand this in the ATmega128 mode In ATmega103 mode it completes in a different way, and the true speed of the EEPROM is available. As I said, this is pure guessing.> The difference in EEPROM timing caused us a problem when porting the > code from ATMega323 to ATMega32.Yes, me too, I had to change three lines of code which were obvious what they were supposed to do. "Send signal to self in 4 ms, because then the EEPROM has terminated any possible ongoing write" I changed the constant 4 ms to 6 ms in the ATmega16 and then the program worked. 12 kB of ATmega163 code required 20 lines changed. The EEPROM timer, the fact that the UART has three stages. Proper way to clear a UART receive buffer is not to read the UDR and assume it then is empty. There is a bit which tells you that it is empty, and this means that you read the UDR until the chip says it is empty. I think that the program could have been written for he ATmega163 in such a way that there would not be any need to change the code. Lesson learned: -- When programming, it is important to understand what datasheet values may change in the future and prepare for this.> Vladimir Vassilevsky > > DSP and Mixed Signal Design Consultant > > http://www.abvolt.com > > Mike Harrison wrote:-- Best Regards, Ulf Samuelsson ulf@a-t-m-e-l.com This is a personal view which may or may not be share by my Employer Atmel Nordic AB
Reply by ●November 1, 20042004-11-01
"Mike Harrison" <mike@whitewing.co.uk> skrev i meddelandet news:6jado0lhhn5f1r0n5tmkm7u8f2cs6j06a6@4ax.com...> On Mon, 1 Nov 2004 20:29:08 +0100, "Ulf Samuelsson" <ulf@atmel.nospam.com>wrote:> > > > >"Tim Mitchell" <timng@sabretechnology.co.uk> skrev i meddelandet > >news:H8LIWLibzjhBFAV2@tega.co.uk... > >> In article <k04co054e0g5rcbn50h2tptfh3i3sg46r8@4ax.com>, Mike Harrison > >> <mike@whitewing.co.uk> writes > >> >Here's a warning that may hopefully save someone else all the hassle > >> >we've just had after migrating > >> >a product to the Mega8515 - there may be a similar issue with other > >> >back-compatible mega parts.. > >> > > >> >We had some code that was originally written for a 90S4414. This moved > >> >to a 90S8515 a while ago when > >> >the 4414 went obsolete. We recently changed to the AtMega8515, again > >> >due to the old part going > >> >obsolete. > >> >We then started seeing apparently random eeprom corruption on some > >> >units. We could write and verify > >> >the eeprom, but after powering off for an hour the data wouldsometimes> >> >be all FFs, and sometimes > >> >correct..... > >> > > >> >After many false leads and much headscratching, I chanced on a subtle > >> >difference between the > >> >ATMega8515 and the old 90S4414/8515 parts, which is not highlighted in > >> >the datasheet ' differences' > >> >section (I have emailed Atmel to suggest they add it..). > >> > > >> >On the Mega version, The EEADR registers are not initialised to a > >> >guaranteed state on reset. They > >> >are initialised to 0 on the old 90S parts. As the code was originally > >> >for the 4414, (which has 256 > >> >bytes eeprom, hence no EEADRH), and then moved with no problems to the > >> >90S8515 (which initilises > >> >EEADRH to 0), there was no code to explicitly clear EEADRH, so on the > >> >Mega8515, we had what amounted > >> >to a 'random page swap' on power-up, and some rather unhappycustomers...> >> > >> I believe this is the (undocumented) case with all registers on all AVR > >> Mega parts - the registers all power up in an undefined state, but as > >> you say on the older AVRs they power up consistently at 0. Has caused > >> some fun when porting code over. > >> -- > >> Tim Mitchell > > > >Thanks, I spread it around internally ! > >However, I think you need to read the datasheet more carefully. > > I don't dispute that the information is in there, but I don't think anyonewould think it reasonable> to read through a 255 page datasheet line-by-line to compare minor detailsto spot changes from a> part that is promoted as a direct replacement. The datasheet should have asection that itemises> EVERY difference, however subtle, so any potential problem areas caneasily be looked at.> > The problem actually 'occurred' a few years ago when we were forced tomigrate from the 4414 to the> 90S8515 when the 4414 was obsolete, then only manifested itself when weagain were forced to change> to a new part due to the 8515 going obsolete. > > Most of us are too busy developing new products to spend a lot of timere-examining code written> years ago that breaks when put on a new, supposedly 'compatible'part.....>I think this email went a bit premature. I meant to say: You need to read more carefully to see that most registers ARE in fact initialized even on the ATmegaAVR. I dont think it is reasonable to expect to see that the EEAR is not initialized and I think it *should* be in the migration document. -- Best Regards, Ulf Samuelsson ulf@a-t-m-e-l.com This is a personal view which may or may not be share by my Employer Atmel Nordic AB
Reply by ●November 1, 20042004-11-01
Ulf Samuelsson wrote:> "Mike Harrison" <mike@whitewing.co.uk> skrev i meddelandet >... snip ...>> >> The problem actually 'occurred' a few years ago when we were >> forced to migrate from the 4414 to the 90S8515 when the 4414 was >> obsolete, then only manifested itself when we again were forced >> to change to a new part due to the 8515 going obsolete. >> >> Most of us are too busy developing new products to spend a lot of >> time re-examining code written years ago that breaks when put on >> a new, supposedly 'compatible' part..... > > I think this email went a bit premature. I meant to say: > You need to read more carefully to see that most registers ARE in > fact initialized even on the ATmegaAVR. > > I dont think it is reasonable to expect to see that the EEAR is not > initialized and I think it *should* be in the migration document.I have been idly following this thread, and as far as I am concernced that new device has a serious bug. It obviously cannot run code developed for earlier products without changes, so cannot be used as a replacement. It would have taken little effort to set that register in a known harmless condition on reset. -- Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net) Available for consulting/temporary embedded and systems. <http://cbfalconer.home.att.net> USE worldnet address!
Reply by ●November 2, 20042004-11-02
> I have been idly following this thread, and as far as I am > concernced that new device has a serious bug. It obviously cannot > run code developed for earlier products without changes, so cannot > be used as a replacement. It would have taken little effort to set > that register in a known harmless condition on reset. > > --Yes, probably a bug, but it is questionable if it is serious. I.E worth doing a new maskset to fix this bug. The bug only affect those that step up from the 4414, and those that assume that registers have a known value at reset. It is generally a good practice to avoid relying on reset values. It is an unknown harmless condition on reset and takes two instructions to fix after reset. The problem is if you do not know about it. -- Best Regards Ulf at atmel dot com These comments are intended to be my own opinion and they may, or may not be shared by my employer, Atmel Sweden.
