Flash in-circuit programming failure

dfridley · **Joined:** Thu Feb 25, 2010 5:02 pm **Posts:** 88

A client of ours has been using the AT91SAM7X128 part in a product for the past 2 years.

The product allows reprogramming the flash in the field and has worked flawlessly since this product was introduced 2 years ago.

Now we are getting newly manufactured boards that are failing when attempting to reprogram the units in the field. BTW: not all boards in the latest manufacturing run exhibit this failure only about 1-2% will fail.

The field reprogramming algo goes something like this:
1) put data into page buffer.
2) write the page
3) verify the write by reading back the data from the flash.

It is this last step 3) where we are failing.
For example if we attempt to write 0xfffff000 we are seeing 0xfbfff000

Has anyone experienced a similar occurance and were you able to identify the cause or have any ideas as to what may be causing this?
BTW: some of the mfg codes for the AT91SAM7x128 are different but we have been unable to correlate the codes to these failures.

dfridley · **Joined:** Thu Feb 25, 2010 5:02 pm **Posts:** 88

Contacted factory about this issue. Will post updates.

dfridley · **Joined:** Thu Feb 25, 2010 5:02 pm **Posts:** 88

Sent failing parts and board to Atmel for further analysis.

We are only seeing this failure with AT91SAM7x128 parts with date codes of 0633 A 6R2889.

Will provide further updates...

dfridley · **Joined:** Thu Feb 25, 2010 5:02 pm **Posts:** 88

Hopefully this helps someone in the future...

Atmel has confirmed that some of the AT91SAM7X devices will fail when programming the Flash via IAP. SAM-BA already has this patch. I am told that this issue is related to a small number of parts with a particular firmware revision. We came across this issue with the following lot and date codes. LotID : 6R2889, Date_Code : 0633

From the Atmel report:
Report Date: March 29th 2010
Atmel Reference #: FA#100561

Quote:

Root Cause:
Due to a test coverage issue at production level, a Flash Programming issue where some devices cannot be programmed correctly has been confirmed recently on SAM7xx devices. The programming issue really depends on the pattern (binary or data) used to program the Flash memory.
The failure rate depends on operating temperature, VDDCORE voltage and process variations. The worst case conditions are reached with a maximum voltage on VDDCORE, 1.95V and at maximum temperature, +85°C.

This issue is related to the programming phase only, thus it is not going to have any influence on Flash content once the device has been programmed correctly.

For applications which require data programming or self firmware upgrade so called In Application Programming (IAP), it is mandatory to apply the below software workaround to modify the Flash Programming sequence accordingly.

Comment:
This has been found in the beginning of mass production and is corrected now.

Here is the recommended work around if anyone is using IAP. BTW Atmel recommends that this be applied for all AT91SAM7x devices that use IAP.

Quote:

The workaround that has been validated by the design, application and product engineering teams is a software workaround which consists in programming the Flash in two steps described just below:

First step: Program even words with autoerase
• load even words to be programmed in the page only
• write even words using autoerase (full page autoerase, + write page mode)

Second step: Program odd words without autoerase
• load odd words to be programmed in the page
• write odd words without autoerase

In order to help the customer, the above sequence has been implemented within a patch for our AT91-ISP Flash Programming Tool named SAM-BA.

Flash in-circuit programming failure

Who is online