S32K344 : Fee issue

[ckouts]

Hello all,

We are currently integrating the FEE (Flash EEPROM Emulation) module into our project and have encountered a recurring issue.

After performing several Fee_Write() operations, the write job consistently fails after approximately three power cycles. Following the third failure, the next power cycle results in a HardFault during FEE initialization or operation.

We would appreciate any insights into potential causes or debugging approaches for this issue.

Additional details:

• The configuration was generated using EB Tresos, identical to the configuration used in the official NXP example project.

• The application code involving the Fee module is minimal and nearly identical to the example (Fee_Init, Fee_Write, Fee_Read).

• It is unusual that the first three write/read cycles succeed, but subsequent ones consistently report MEMIF_JOB_FAILED, and after the next reset a HardFault occurs.

• We are using S32K3X4EVB-T172

Has anyone experienced similar behaviour, or could you suggest what might cause a Fee job to fail after several successful operations?
Any hints or debugging recommendations would be greatly appreciated.

Thank you in advance for your support,
Chris

[ckouts]

Thanks a lot for your prompt response. I have tried both of your config suggestion but with no luck. 
Eventually, the issue was resolved by slightly modifying the initialization order. Previously, I had 

Gpt_Init(&Gpt_Config);

(Fee_Init ( with all the appropriate function calls)

Gpt_StartTimer()

Gpt_EnableNotification() ( To trigger a periodic interrupt). After moving Fee_Init() after the Gpt_EnableNotification driver works smoothly. Somehow this initialization order interfered with the Fee driver I guess and after 3 power cycles could not write to Fee.
Is there any deeper/better explanation on that?

 
Thanks in advance,
Chris

[danielmartynek]

HI @ckouts,

I don't see the connection between Fee and Gpt.

Do you use Gpt notification to call FEE/MemAcc APIs?

Regards,

Daniel

[ckouts]

Hello again and thanks for your answer.
Not really. I just used the example were all the Fee Read/Write operations were executed in blocking mode(exactly as the example but I embedded it in my existing project) before the Gpt initialization as described above. After modifying the init order the Fee example worked ok.

[danielmartynek]

Hello @ckouts,

Given the inconsistent behavior of the FEE, please verify that the system clock configuration matches one of the officially supported options listed in the Reference Manual - such as Table 157, Option A: High Performance Mode (CORE_CLK @ 160 MHz). 
Additionally, confirm that all compiler and linker settings strictly follow the guidelines provided in the RTD release notes. The RTD has been validated with the specific configuration.

Thank you,

BR, Daniel

[danielmartynek]

Hi @ckouts,

Could you please test with the following configuration settings?

• FeeBlockAlwaysAvailable = 1
  This ensures immediate access to the Fee blocks after a reset.

• FeeImmediateData = 1
  This setting may help reduce the risk of data loss during resets.

For further details, please refer to the FEE User Manual, which is available in the installation directory of the RTD.

If these changes do not resolve the issue, share the following:

• The configuration .xdm files
• The relevant source code containing all FEE API calls

Regards,

Daniel