Our software application supports a custom Flash File System (FFS) that uses the upper 24KB of the flash of the AT91SAM7XC512 as storage medium. The self-programming API of the EFC is used by our flash driver to update the flash pages of the files in the file system. Every now and then re-programming a flash page goes wrong. Although the EFC does not report an error, one or more bits in a flash page are not programmed correctly.
All relevant code and data for the flash driver is of course located in RAM.

Is there anybody else who uses the EFCs in a similar way and encountered similar problems?

Notes:
1. We have seen this problem only with AT91SAM7XC512, never with AT91SAM7XC256. For both microcontrollers we use the same flash driver, which is compiled with same GNU toolchain.
2. The problem only occurs when exactly one 16-bit word in the page needs to be changed. It never occurs when more than one word in a page needs to be changed at the same time.
3. Of all attempts to change one word in a page about 20 to 40% will fail. If the error occurs, then the workaround is to clear the page erase bit (NEBP) and try again. (i.e. re-program same page with same data) This resolves the situation every time. However, it takes one extra erase cycle and therewith reduces the life time of the chip.
4. If the error occurs, then most of the time only one bit is wrong. Which bit is random, although the faulty bit is always in the word that needed to change or in one of its two neighboring words. (address-1, address+1)
5. The error occurs with both EFC controllers of the AT91SAM7XC512. We tested this by an experiment which involved moving the FFS storage area down to the low end of the internal flash memory.
6. We have tested/tried/double checked the following aspects, none with any success – in each case the problem persisted:
• Interrupts disabled during programming.
• Dummy read just before writing programming command to EFC Flash Command Register. (FCR)
• Pause before reading from flash after EFC signals programming is complete with FRDY bit.
• Increased number of flash wait states.
• Double checked FMCN value. Tried slightly larger value.
• Double programming. Does not work - EFC is ready immediately.
• SPI bus DMA disabled during programming.
• Brownout detector + reset are enabled through GPNVM0 and GPNVM1 bits - no brownout resets occurred ever.

Regards,

Robert

ATMEL flash arrays on CPU die have a long history of being very flaky.

Some require that you write all the even 16-bit words first, then all the odd ones. You should speak to an FAE as this is a mine-field.

See comments in flashd_efc.c (at91lib)

// Write page
// Writing 8-bit and 16-bit data is not allowed
// and may lead to unpredictable data corruption
#ifdef EFC_EVEN_ODD_PROG
// Write even words first with auto erase
..
// Then write odd words without auto erase


Another trick commonly used with flash is to write all cells to ZERO before erasing, so as to cause all charge levels to be uniform/consistent after the subsequent erase process.

Hi CptTitanic,

Thanx for your suggestion - i tried it, but it did not help...

With help of Atmel support we made some progress, it now looks like the problem only occurs with chips that have EFC v1.13. We have one AT91SAM7XC512 with EFC v1.12 and it does not show the problem.

The EFC version can be read from the EFC_VR register. This EFC_VR register is not documented in the datasheet of the AT91SAMXC family, but it is defined and described in the API header files provided by Atmel in AT91LIB. (e.g. file AT91SAM7XC512.h)

The AT91SAM7XC256 that we use in older products also has EFC v1.12 and does not show the EFC problem either.

Again with the help of Atmel support we managed to pin point the problem.
Atmel stated that the AT91SAM7XC512 contains an ECC in the EFC for flash error detection and correction. This ECC was not implemented in the revision A and B of the AT91SAM7XC256 the we used until now. The errors we see occur because of this new ECC and the way we program the flash.

According to Atmel our way of re-programming is not following their recommendations/requirements for flash. Our FFS tries and re-programs 32-bit words that have already been programmed before, but only attempts to re-program bits that have value one. Atmel says re-programming is not allowed, even if it involves only programmming of one-bits to zero-bits. Each 32-bit word may only be programmed once. If a 32-bit word needs to be re-programmed, then it's page must be erased first.

I stated the datasheet does not explicitly mention that re-programming this way is not alllowed and that it is a common behavior of flash-dedicated file systems to do so. They agree and promised to update the datasheet for it...

BTW: Not the following:
- There is no way to disable the new ECC or influence it by means of software. It has no API, it is just part of the silicon around the EFC.
- Rev C and up of the AT91SAM7XC256 also contain the new ECC

Hi

Do you know whether the addition of ECC to the flash also affects SAM7Xxxx parts (without the C)?
We have used the SAM7X128, SAM7X256 and SAM7X512 in a number of products since 2006, all of which are still in production and the ECC would cause these to fail without suitable reworks (since some Flash operations change content on a byte-basis).

Regards

Mark