Warning on migrating to ATMega8515 - eeprom problem

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 to
Mike Harrison
Loading thread data ...

just had after migrating

back-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 to
Meindert Sprang

In article , Mike Harrison writes

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 to
Tim Mitchell

"Tim Mitchell" skrev i meddelandet news: snipped-for-privacy@tega.co.uk...

Thanks, 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
 Click to see the full signature
Reply to
Ulf Samuelsson

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

formatting link

Mike Harris> Here's a warning that may hopefully save someone else all the hassle we've

just had after migrating

back-compatible mega parts..

90S8515 a while ago when

the old part going

could write and verify

FFs, and sometimes

difference between the

datasheet ' differences'

state on reset. They

4414, (which has 256

(which initilises

Mega8515, we had what amounted

Reply to
Vladimir Vassilevsky

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 to
Mike Harrison

"Vladimir Vassilevsky" skrev i meddelandet news:W%whd.4189$ snipped-for-privacy@newssvr11.news.prodigy.com...

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.

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.

--
Best Regards,
Ulf Samuelsson   ulf@a-t-m-e-l.com
 Click to see the full signature
Reply to
Ulf Samuelsson

"Mike Harrison" skrev i meddelandet news: snipped-for-privacy@4ax.com...

sometimes

customers...

would think it reasonable

to spot changes from a

section that itemises

easily be looked at.

migrate from the 4414 to the

again were forced to change

re-examining code written

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
 Click to see the full signature
Reply to
Ulf Samuelsson

... snip ...

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.
 Click to see the full signature
Reply to
CBFalconer

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
 Click to see the full signature
Reply to
Ulf Samuelsson

I consider it a bad bug. You can't have code that runs on both machines, it will either have illegal instructions, or fail to initialize.

--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
 Click to see the full signature
Reply to
CBFalconer

AVR code is not binary compatible between chips because the I/O locations move around. Even when they don't there are other issues. The I/O on the ATmega88 is in the same position as in the ATmega168 buts since the ATmega168 uses > 8KB code space, all the vectors are 32 bit.

Thus you have to recompile.

If you accept source compatability, then there are several way you can proceed. Conditional compilation is one way. If I want to use the same code for several chips I generate a couple of files. config.h compatability.h - defines fixes needed for this chip compared to my "base" chip.

For this specific case, I can use one SRAM location, or a CPU register as EEARH.

compatability.h thus contains. #ifdef AT90S4414 __regvar __no_init BYTE EEARH @ 10; // use r10 #endif

EEARH = 0;

results in clr r10 being generated.for the 4414, and EEARH is set to 0 for all others. r10 is normally not used anyway by the IAR compiler.

You can thus run the compiled result of the same source code on both CPUs and you cannot run the same binary anyway, so it is not so nasty as you describe it.

It is a valid complaint that the AVR is not binary compatible, but I am afraid that the AVR architecture will not allow this for the mega series. The tiny series which is always < 8 kB could theoretically have this. In practice with the limit of only a few bitadressable registers, those are going to be used in an as efficient manner as possible.

With the ATmega48/88/168 Atmel tried to make parts as compatible as possible within that family, and this is what will happen in the future. One base design with derivatives using different memory sizes, few or no changes between parts in different memory sizes.

There will always be some small exception to the rule. The goal is really no modifications of the source code, binaries are less important.

--
Best Regards,
Ulf Samuelsson   ulf@a-t-m-e-l.com
 Click to see the full signature
Reply to
Ulf Samuelsson

I don't think there would be any problem writing non-existant registers on the

4144 - it's not an 'illegal instruction'
Reply to
Mike Harrison

Caution! Unless you specifically instruct the compiler to not use r10, it DOES use it. An r10 is a must-preserve register, so even when you dont inline assembler but call externally linked assembler code, you must not scratch r10.

The compiler can be configured to not touch registers r15 and below. To keep clear r10, you effectively have to forbid usage of r10-r15. Note that you also have to recompile the runtime library (clib/dlib), because the precompiled versions that come with the installation binary are compiled for full register usage.

Reserving R10-R15 wont result in lots of speed reduction. Much code compiles well without actually needing r10. Thats probably why you concluded that r10 is not used. However, if you compile complex code that can take advantage of many registers, r10 will be used. Try for example a cryptographic algorithm or other large function with lots of autovars and only few function calls. Set optimization to 9 and see yourself.

Marc

Reply to
jetmarc

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.