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 ?