Non volatile memory on S32K344

[rishabh_10]

Hello,

I am working on non-volatile memory (NVM) for S32K344 as we don't have any dedicated eeprom on it, I am using its flash memory to store my data, I have created a data write and read block by using mask. Now when I am using it is giving me unexpected errors like

1.) if I enter data randomly on freeMaster(software) then it doesn't retain it, and when I am entering the data in sequence then it is retaining it.

2.) and sometimes when I enter the data maybe for parameter 1 then it gives the data to parameter 1 and 2 both, when this shouldn't happen.

3.) When I create parameters 10 onwards, they are also not retaining the data.

I don't where I am going wrong about this.

I have attached the Matlab, Simulink and the freeMaster file for reference.

[FlorinCiuca]

Hello @rishabh_10!

Thank you for your interest in Model-Based Design Toolbox for S32K3!

I downloaded the attached archive and I had a look on the Simulink model and on the generated code. 

After the initial analysis, I have the following comments:

• the Mem_43_INFLS blocks are used correctly, so the presented issues are not caused by incorrect parameters fed to them.
• however, with the current model, where 9 pairs of NVM Read/Write subsystems are commented out, the generated .c file has 32 operation function calls(Read, Write, Erase, BlankCheck) and only one MainFunction call and this is most likely what causes the observed issues. 

The way Mem_43_INFLS Driver is designed, the operation specific function calls(Read, Write, Erase, BlankCheck, HwSpecificService etc.) only check if the parameters given to them are correct and in range and they only prepare the driver for the data exchange. The actual data transfer and/or flash memory manipulation are performed during the MainFunction call only. For an operation to be successfully completed, several MainFunction calls may be required, depending on the size of the data to be read/written/compared/erased and on the Mem Read/Write Page Size, which is configurable from the Mem_43_INFLS Driver form S32CT or from EB Tresos. (e.g: if the Write function receives a buffer of 40 uint8 values and Mem Write Page Size is 8, the MainFunction will be triggered 5 times before completing the write job). Ideally, any job request should be immediately followed by MainFunction calls until the driver becomes idle. Now, there are 2 faulty scenarios possible(and , from what I observed, both are present in this given example):

1.  When a job request comes when the driver is busy with another. In this case, the second job will be rejected and lost if not triggered again after the driver finishes the ongoing job.
2.  When 2(or more) successive job requests come without a MainFunction call between them. In this case, the driver will occupy its internal buffers with data from the first job, then overwrite it with data from the second job and so on. Depending on the sizes of the data to be handled, this can sometime work, but it is not desirable nor predictable and should not be tried.  

On this specific example, where the 3 issues are presented, I can provide the following conclusions:

1.  For first scenario, this is most likely a synchronization issue. When a variable is changed in Freemaster, the Driver is probably busy with another job, and the current command is ignored.
2.  The second issue is explained in bullet 2. one paragraph above. Since you are trying to write 8 bytes of data at a time and the Write Page Size is also 8, depending on previous operations, the Mem Driver sometimes has enough space in its internal buffers for both parameters and they are both written successfully(although job is successful, it is still a faulty behavior since only one parameter was meant to be written). Other times, the driver is either busy doing other jobs or only has enough space for one job parameter data.  In order to ensure a correct and consistent behavior, after every parameter write, the "MainFunction Trigger Subsystem" should be copied to ensure the data is written before any other data write is attempted.(this also applies for the Read/Erase/BlankCheck operations inside the model)
3. This third issue is similar to the one above, but with more read/write operations involved. The more concurrent operations are attempted without MainFunction calls in-between them to ensure correct memory handling, the higher the chance to never see any variable change and for the Mem driver to return errors.

My suggestion for this model would be to ensure each NVMWrite / Nvm Read subsystem has its own dedicated "MainFunction Trigger Subsystem" to prevent conflicts and overwriting of job parameters.

I hope these explanations will be of help to you and others. Please let me know if the issues are still persistent or if I can assist you in other ways.

Best regards,

Florin.