Flash FlexNVM reading problems

[lohrsistemas]

Hello,

I'm using the FlexNVM memory from 0x10000000 to 0x10007FFF (32kB) to save data in the run program. When I fill all the memory I erase and log again, so in the routine I search for the next free address (0xFF) and write what I need.

In my routine to look for the next free address, where I read each address from the memory, some address I can't read, it goes to a default handler and WDT resets. The solution is erase all the memory, so this problem doesn't happen anymore.

But my question is: is necessary to erase this region of memory before I first use? This problem is random, only in some chips it happens.

[danielmartynek]

Hello,

The phrase you are writing to must be erased. And the smallest portion of DFlash that can be erased is a sector.
It looks like you get ECC errors. When you writing to a phrase, do you see any error flags?

Regards,
Daniel

[lohrsistemas]

Hello,

Thanks for reply. In fact this is happening when I read the address, at this moment I dont write or erase anything, because I read all the memory to look the free address, like this:

__no_init unsigned char flash_logger[32768]   @ 0x10000000;

    for(aux=0; aux<32768; aux+=8)
    {
        if(flash_logger[aux]==0xFF)   
        {
            ret = aux;
            break;
        }
    }

Is some cases when I execute "if(flash_logger[aux]==0xFF)    " it goes to a default handler. My doubt is at the first time, if I need to erase all the flash memory before read. This is random so I'm not sure.

What I can do is prepare a logic to erase all the memory at the first use, but in this case I need to use other flash section to save a simple flag.

Regards

[danielmartynek]

Hello,
The DFlash block should be erased if you didn’t write anything to it. Anyway, you can verify that it is not weakly erased using Read 1s Block command and selecting ‘User’ margin (Section 36.5.11.1, RM r.7).

It would be good to find out what the default ISR means. Could you check the S32_SBC[CFSR] register and BFAR register in case of a precise bus fault?

Are you sure the code you are using is correct, have you tried simply with a pointer, something like this:

uint32_t *ptr = (uint32_t*)0x10000000;
uint32_t data, address, i;

for(i=0; i<0x7FFF; i+=4){
  
   data = *ptr++;
  
   if(data == 0xFFFFFFFF){
      address = (0x10000000 + i);
      if(address == 0x10007FFC){
         __asm__("BKPT");
         ptr = (uint32_t*)0x10000000;
      }
   }
}‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Regards,
Daniel

[lohrsistemas]

Hello Daniel,

The DFlash block should be erased if you didn’t write anything to it. Anyway, you can verify that it is not weakly erased using Read 1s Block command and selecting ‘User’ margin (Section 36.5.11.1, RM r.7).

I've implemented this, but it only works when the DFlash Block is erased, it doesn't work to verify the integrity of flash without erase. In my case the problem is read the flash in the first time that the chip is power on.

I've found in "fsl_flash_driver_c90tfs" the function "FlashReadOnce", that return "FTFx_ERR_ACCERR" if some access error happens. But it only works for the P-Flash, is there any way for I read the D-Flash via FCCOB command? In the RM I did't find.

About the default ISR I will check when it happens again.

Thanks for reply.

Regards.

[danielmartynek]

Hi,

I would check all the information provided about the exception. 

You can refer to: Fault handling on S32K144 

Regarding the FlashReadOnce fucntion, please see Section 36.4.2.1, RM r.7.

This function is for the IFR Program Once field only.

There is no flash command for DFlash reading.

What do you see in the debugger's memory view?

Regards,

Daniel

[lohrsistemas]

Hello Daniel,

Thanks for reply.

It happens again with your function to read the memory, exactly in this line: "data = *ptr;"

Here what I have in the memory:

And the problem happens when I read the address 0x10000000, the others it doesn't happen.

Here the register that you asked for:

What could be happening?

Regards

[danielmartynek]

Hello,

So there is no fault exception. Maybe double-bit ECC error indicated by FERSTAT[DFDIF] flag.

But it doesn't explain why there are the some data if you didn't write anything to the DFlash block.

Is there a problem erasing the DFlash block?

Regards,

Daniel  

[lohrsistemas]

Hello,

Is there any minimum time between writing flash or between writing and readind flash? I still have this problem (when it shows "??????" in the memory).

Debbuging I could see that only in the first address 0x10000000 it takes a long time to appear in the memory what I had written before and maybe if I read this address while it doesn't update here could be the problem?

Thanks.

[danielmartynek]

Hello,

The data are ready once the Flash operation is complete. But please disable the D-Flash prefetch buffer in MSCM_OCMDR1[OCM1] register before any D-Flash content modification. The buffer is not updated by the flash command so it will return old data.

Regards,

Daniel

[lohrsistemas]

When the hard fault occurs, now I could get the important registers:

In the address that BFAR shows I have the "????" data:

I will implement your suggest about the BusFault Handler, but would be correct fix the problem that is causing "???" data.

Thanks.

[lohrsistemas]

Hello Daniel,

Thanks for reply. Taking a look in your observation I get this value to the MSCM_OCMDR1 register:

In RM 34.4.2.19.4 we have:

So is this value ok? "10" => "Speculation for instruction enabled and speculation for data disabled"?

Other question, what you suggest is this in the code:

MSCM->OCMDR[1] &= ~MSCM_OCMDR_OCM1_MASK; /* Disable buffer */

WriteFlashFunction();

MSCM->OCMDR[1] |= MSCM_OCMDR_OCM1_MASK; /* Enable buffer */

Best Regards.

[danielmartynek]

Hello,

The default MSCM->OCMDR[OCM1] value is 0b00.

That means: “Speculation for both instruction and data enabled”.

So, it’s the other way round:

MSCM->OCMDR[1] |= MSCM_OCMDR_OCM1_MASK; /* Disable buffer */
WriteFlashFunction();
MSCM->OCMDR[1] &= ~MSCM_OCMDR_OCM1_MASK; /* Enable buffer */‍‍‍

Regards,

Daniel

[lohrsistemas]

Hello Daniel,

Thanks for reply.

I've implemented this check before any writing or erasing flash process:

while((FTFC->FSTAT & FTFC_FSTAT_CCIF_MASK) == 0) ;

It verifies if there is any operation in progress, and until now I haven't had the problem.

The SDK "fsl_flash_driver_c90tfs", at my look, doesn't verify this point.

Regards.

[danielmartynek]

Hello Lohr,

Yes, this check should be definitely there.

Regards,

Daniel

[lohrsistemas]

Hello Daniel,

No, there is no problem when I execute the function, it returns "FTFx_OK", including in the verification (FlashVerifySection()) function. But generally the solution is perform the erase function again.

Because this I asked if there is some error access to the DFlash...

I'm looking what else it could be. If you have another tip please let me know.

Thanks for reply.

Regards