Fee interation with raw flash writes for internal Flash

[dtyree]

We are using  s32K324 and RTD S32K3_RTD_2_0_0_D2203_ASR_REL_4_4_REV_0000_20220331

I have an Flash update routine that uses C40_Ip_MainInterfaceSectorErase and C40_Ip_MainInterfaceWrite to put data at an explicit location in memory (linker is set for a/b boot swap), and a Fee interface (eeprom emulation) to store persistent data.

I have a If no writes are done to the Fee interface (only reads), The Flash update routine  works fine. If a Fee write is done (complete), and then the Flash update is done a the flash fails to write.

1) C40_Ip_pFlashBaseAddress->MCRS volatile uint32_t  is 0xc100 (Hex) after Fee write before update is started.

2)  C40_Ip_MainInterfaceSectorErase is called Flash is erased and C40_Ip_pFlashBaseAddress->MCRS volatile uint32_t 0x8100 (Hex). The data appears to have been erased. MCR is 0.

3) C40_Ip_MainInterfaceWrite is called for writing the update and it fails on the first access. C40_Ip_pFlashBaseAddress->MCRS volatile uint32_t is still 0x8100, and it fails in C40_Ip_MainInterfaceHVJobStatus FLASH_MCRS_PEG_MASK != ErrorFlags.

So, the erase was "done" and competed for the range, confirmed with flash dump. It appears to be successful though the MCRS is 0x8100 instead of 0xC100. That state remains through the write sequence (unlock passes) and fails on step 3 above.

What am I missing to check/clear after the flash erase?

[danielmartynek]

HI @dtyree,

The RTD you use is 3 year old. Can you use the up-to-date revision?

The FEE driver requires the FLS driver, because FEE sectors are configured by FLS.

If there is FLS driver in the project, why you use C40_Ip instead?

Do you have HSE_FW installed?

Is the system clock set precisely to one of the clock options, e.g. 24.7.2.4 Option A - High Performance mode (CM7_CORE_CLK @ 160 MHz)?

Can you share the project so that I can test it?

Regards,

Daniel

[dtyree]

We cannot update to 3.0 at this time. First attempt at moving to 3.0 broke all the tools, the build, and would not result in a clean migration. I have unkind thoughts of the s32 designer build tools/methodology.

We are using the HSE (Firmware installed), but only to manage the a/b switch at this time.  I'd guess this could cause an interaction as well when we start to use more HSE features.

I'm not using C40_Ip purely out of ignorance. I was working off the a/b update examples and rolled with it. This is the only function that directly writes to blocks of internal flash. If C40_Ip was better documented, I'd probably move to it.

I'll check the clock, last I recall that was how it was set.

This is reproducible if you follow the HSE install and use the A/B swap example (it does not use C40_Ip ) with an additional FEE write.

We have it working now with those calls I mentioned. Additionally, we are now locking against preemption during the write of a block.

[danielmartynek]

Hi @dtyree,

The current RTD is 6.0.0 already.

I would recommend that you have a separate S32DS IDE installation for each RTD version and its compatible extensions, in that case, there will be no problem.

Every RTD release notes specifies compatible HSE_FW revision. Even though it might not cause any issues with other revisions, we cannot guarantee that.

RTD 2.0.0 release notes:

Can you maybe share the project so that we can test it?

You can share it publicly via a support ticket.

You use S32K324 that has two decoupled cores.

What is the secondary core doing while the failure occurs?

Regards,

Daniel