Hello,
we are testing a board we developed using the SAM7X512 CPU.
We are performing environmental testing right now, and seems this CPU does not comply with the operating temperature limits specified in the datasheet.

The datasheet states that the operating temperature should be -40 to +85°C, but when the ambient temperature reaches 78/79°C the CPU starts to read garbage from the flash memory.

In particular, the issue here is with the 2nd bank of flash (EFC1). We made a test firmware that continuously compute the CRC of the whole flash. This test fails when the ambient temperature reaches 78/79°C. If we limit the test in order to check only the first bank (EFC0, the first 256K of memory), the test runs fine until the expected operating temperature (86/87°C).

The flash register timings are set correctly for both banks.

We could not find any errata sheet concerning this issue.

Do you have any advice on this matter? I think this is a serious hardware bug in this CPU.

If we can't resolve this problem we will be forced to re-design the board with another CPU :-(

hello,
3 questions:
What is your MCK?
How many wait states do you use?
What's the revision of your chip?

regards
gerhard

Hi Gerhard,

Our MCK is 52.8MHz, we use 2 read wait states and the chip revision is A.

We also tried to increase the number of wait states to the maximum (3), but the behavior is still the same.

hello,
your settings seem to be ok.
did you made the test with several boards/chips?
what happen in case of reducing MCK?
did you contact atmel support?

regards
gerhard

Yes, we have the same behavior on at least 5 different boards.
I could slow the MCK for testing purposes, but the application needs the CPU to run at this clock value in order to generate other synchronization signals for ADCs and DC/DC converters. I will try to contact Atmel support then.

With the observed failure, are there patterns to the bits in memory that are failing (bits within words, bits within page, stuck at one, stuck at zero, etc)?

Not to discount your problem and the real flash memory issue there are/have been out there, but if the read side is failing, and wait states aren't working, you should look at the writing.

One might want to consider very carefully how the array was erased and programmed. And the conditions under which these operations occurred.

Certainly other parts have the FMCN (Flash Microsecond Cycle Number) that is quite critical, and clock speed dependent. Each array has it's own.

Another method commonly used to ensure the array is cleanly, and uniformally erased, is to program the array to ALL ZERO prior to erase.