On S32K148 DFLASH read after program is wrong

[freddy_ben-zeev]

I've ported a file system (LittleFS) to my system. It's configured to program blocks of up to 64 bytes using the SDK flash program function. The block read is done by direct memory access.
The file system after programming a block reads it back and verifies it. Many times the verify fails. Any idea why?

Freddy

[lukaszadrapa]

Hi,

some typical troubles when programming the flash:

- do you check return value of FLASH_DRV_Program function? Is it always STATUS_SUCCESS?

- are you aware that flash start address and size must be aligned to 8 bytes?

- from RM: "A Flash memory location must be in the erased state before
being programmed. Cumulative programming of bits (back-to-
back program operations without an intervening erase) within a
Flash memory location is not allowed. Re-programming of
existing 0s to 0 is not allowed as this overstresses the device."

These are first things to check. More details would be needed if this doesn't help.

Regards,

Lukas

[freddy_ben-zeev]

All those issues were verified.

Another interesting point:
1. I'm running under the design studio debugger.
2. I set a breakpoint where the read back verification fails and run until I get there.
3. I examine the flash with the debugger - it is correct.
4. I force the code to re-execute the verification - it passes.
5. If I execute the verify multiple times in a loop without break point it fails for as many time as I execute the loop (tried 100 times). 

[freddy_ben-zeev]

More information:

The software programs the DFLASH as blocks of 64-bytes (aligned on 8 bytes boundary). After such a write it uses memcpy to read back the last written block to a RAM buffer. When the problem happens this read back buffer has 8 FF's in the first 8 bytes (the rest of the buffer is correct). The flash from where is was read seems to have the correct data.
I've added after the memcpy a memcmp between the read back buffer and the DFLASH to check if the data was copied correctly - and the problem disappeared.
I don't like such unexplained situations...

Freddy

[lukaszadrapa]

Hi Freddy,

could you try to disable cache memory to see if it makes a difference?

Regards,

Lukas

[freddy_ben-zeev]

The cache was not enabled. PCCCR is 0.

[kef2 · Accepted solution]

Hi,

Flash speculation seems being enabled by default. OCM1 field of OCMDR1 is 00 by default. Tricky note "Value 0 means enable", Enable-Enable, so both instruction and data speculation are enabled.

Edward

[freddy_ben-zeev]

Setting bit 4 in OCMDR[1] to '1' solved the issue.

Thanks.