Flash Write Verify error with read margin = normal (KL17/KL27, KSDK v2)

Showing results for 
Show  only  | Search instead for 
Did you mean: 

Flash Write Verify error with read margin = normal (KL17/KL27, KSDK v2)

Contributor III

I've encountered some unexpected behaviour using KSDK v2 to verify flash writes, with different settings for the read margin.

The problem was first observed with a bare metal board running a KL17Z processor and some custom code, but I've since replicated it using a FRDM-KL27Z and one of the SDK examples, as shown below.

Referring to the Flash driver sample code "flash_erase_program_verify" from the SDK v2, it uses the following (line 189) to verify a previous flash write:

result = FLASH_VerifyProgram(&flashDriver, destAdrss, sizeof(buffer), buffer, kFLASH_marginValueUser, &failAddr, &failDat);

The above sample runs ok with the read margin set to "kFLASH_marginValueUser". However if the read margin is changed to "kFLASH_marginValueNormal", the verify fails with a return result of "kStatus_FLASH_AccessError". The SDK manual indicates this means "Invalid instruction codes and out-of bounds addresses".

The reference manual for the KL27Z (and KL17Z) describes the read margin settings as follows:
"Only the 'normal' read level should be employed during normal flash usage. The nonstandard, 'user' and 'factory' margin levels should be employed only in special cases.
They can be used during special diagnostic routines to gain confidence that the device is not suffering from the end-of-life data loss customary of flash memory devices."

It seemed to me that using a Normal read margin would be more appropriate for our production code, hence we used kFLASH_marginValueNormal during our flash write verifies. I haven't seen anything in the SDK or processor reference manuals which would suggest this should cause an access error.

Have I overlooked something or misunderstood how the verify command works, or how the read margins should be set ? Is anyone else able to replicate this behaviour ?

3 Replies

NXP TechSupport
NXP TechSupport


Regarding the return value of the FLASH_VerifyProgram(), as you know that there are three types of the flash margin value:

    kFLASH_marginValueNormal,  /*!< Use the 'normal' read level for 1s.*/
    kFLASH_marginValueUser,    /*!< Apply the 'User' margin to the normal read-1 level.*/

Different safety margin level input represents different safety level or flash degrading parameter. I copy the part from UM.

The 'user' and 'factory' levels become, in effect, a minimum safety margin; i.e. if the reads
pass at the tighter tolerances of the 'user' and 'factory' margins, then the 'normal' reads
have at least this much safety margin before they experience data loss.
The 'user' margin is a small delta to the normal read reference level. 'User' margin levels
can be employed to check that flash memory contents have adequate margin for normal
level read operations. If unexpected read results are encountered when checking flash
memory contents at the 'user' margin levels, loss of information might soon occur during
'normal' readout.

The 'factory' margin is a bigger deviation from the norm, a more stringent read criteria
that should only be attempted immediately (or very soon) after completion of an erase or
program command, early in the cycling life. 'Factory' margin levels can be used to check
that flash memory contents have adequate margin for long-term data retention at the
normal level setting. If unexpected results are encountered when checking flash memory
contents at 'factory' margin levels, the flash memory contents should be erased and reprogrammed.

I have admitted that the part in UM is unclear.

Hope it can help you


Xiangjun Rong

0 Kudos

Contributor II

I have this same problem on a K20DX256VLL7 with flash driver 2.3.1 (in fsl_flash.h).

I have also read the manuals, as geoff_s has, and Xiangjun's answer is not helpful, as it doesn't make sense. How does the User level work but Normal level fail, if we are supposed to use Normal level?

If anyone has any answers, feel free to reply...

0 Kudos

Contributor III

Thanks Xiangjun.  Unfortunately that does not help.  I had already read those paragraphs in the user manual.

In summary, the problem I have is that VerifyProgram succeeds if a "User" margin is used, but fails with an access error if "Normal" margin is specified.  I have reproduced this behaviour on two separate boards with different processors, so I doubt it is actually a hardware issue.  It seems more likely to me to be a software bug in the SDK.  Perhaps you could try replicating this with a FRDM-KL27Z board using the above code ?

0 Kudos