Write to EEEPROM stalls application

[jmap006]

Hello,

I am designing an application running on the S32K144-EVB that utilizes the EEEPROM. The application does not use the S32 SDK.

For preparation, I have read through the following documentation:

• A11983.pdf
• S32K-Reference Manual regarding EEEPROM, etc.

For actual development, I have referenced the following source code:

• EEEPROM SDK Example https://community.nxp.com/t5/S32-Design-Studio-Knowledge-Base/Example-S32K144-EEEPROM-usage/ta-p/110...
• EEEPROM no SDK Example https://community.nxp.com/docs/DOC-340625
• S32 SDK RTM 4.0.1 source code i.e. platform/drivers/src/flash/flash_driver.c

Thus far, I have successfully got the D-Flash E-Flash Partition working, using the launch flash command executed from SRAM and not from P-Flash. Furthermore, have executed the SETRAM command to make the FlexRAM available for Emulated EEPROM. 

I receive the expected codes back when reading the following:

uint16_t s32k144_Dflash_Eflash_verify(void)
{
    uint16_t depart_code = (uint16_t)((SIM->FCFG1 & SIM_FCFG1_DEPART_MASK) >> SIM_FCFG1_DEPART_SHIFT);

    uint16_t eeeram_code = (uint16_t)((SIM->FCFG1 & SIM_FCFG1_EEERAMSIZE_MASK) >> SIM_FCFG1_EEERAMSIZE_SHIFT);

    // depart_code = 8
    // eeeram_code = 2
}

Have done the linker file changes to allocate 4 kilobytes at address 0x14000000. With these changes, all ground work is done to use EEEPROM.

The problem I'm experiencing is when writing to the FlexRAM area. The very first write straight after doing the D-Flash E-Flash Partitioning is successful where I assign an integer. Then after doing a reset and executing a EEEPROM write there after stalls the application. Interestingly, when a reset is done after the stalled application scenario, the EEEPROM write was successful as reading it back shows the intended value is read back.

The write functions confirm that CCIF = '1' and EEERDY = '1'

uint8_t s32k144_eeeprom_write_32bit(uint32_t* dest, uint32_t data)
{
    if (!dest)
    {
        return EEE_PARAM_ERR;
    }

    if ((FTFC->FCNFG & FTFC_FCNFG_EEERDY_MASK) == 0UL)
    {
        return EEE_NOT_READY;
    }

    if ((FTFC->FSTAT & FTFC_FSTAT_CCIF_MASK) == 0UL)
    {
        return EEE_BUSY;
    }

    if (data != *dest)
    {
        *dest = data; // calling this a second time around stalls the application
    }

    return EEE_SUCCESS;
}

Have tried nesting the above write functions in DISABLE_INTERRUPTS() and ENABLE_INTERRUPTS() but no difference in behavior.

Anything suggestions of other things to try or point of what I have missed would be much appreciated. I can provide a zip code example for debug purposes.

Regards,

Josh

[Rahul_Kalvem]

What is the solution if the application fails using the MBDT tools? any solution?
I'm storing the data to the default address 0x14000000, and I'm using RAppID Bootloader to download the code to the board as suggested in another blog.

[jmap006]

Hi @Rahul_Kalvem 

I never tested out the EEEPROM feature with S32K144 MCU using MBDT tools.
My solution is merely a bare-metal implementation.
It would be difficult to know what the solution is.

I would guess the Bootloader would be effecting the EEEPROM to function with your MBDT designed application.

[Rahul_Kalvem]

Thanks for your reply @jmap006 
Using OpenSDA to download the code makes the board to go into continuous reset mode (D1 RED LED always on). There is a limitation when it comes to EEPROM and OpenSDA.
It was suggested to use RAppID bootloader if the model contains EEPROM blocks.

With RAppID BL, the program download is fine but the EEEWrite function stalls the application sometimes.

[jmap006]

If your S32K1xx FlexNVM block is configured (or partitioned) to load during reset, then the FlexNVM may not be ready in time (i.e. EEERDY not equal to '1'), when you invoke EEEWrite().

More detailed information can be found about using EEEPROM in Application Note AN11983.
https://www.nxp.com/docs/en/application-note/AN11983.pdf 

I think you maybe experiencing the same issue I had.

Before you invoke EEEWrite() in your MBDT application, place the same conditional guard as @danielmartynek recommended in my scenario. The conditional guarding is shown below. You may be able to place this somewhere as part of your S32K1xx platform initialization or just before you invoke EEEWrite().
Note: I'm not familiar with MBDT so I assume you have access to alter the Auto-Generated source code.

From my investigation, the amount of time it takes for FlexNVM to be ready, was in the order of ~30 milliseconds. 

// Wait for EEEPROM to be ready.
while((FTFC->FCNFG & FTFC_FCNFG_EEERDY_MASK) != FTFC_FCNFG_EEERDY_MASK)
{
}

 If the FlexNVM is not configured to load during reset, the FlexNVM has to be commanded to load.
The FlexNVM can be self partitioned by the S32K1xx application.

Best of luck @Rahul_Kalvem 

[danielmartynek]

Hi @Rahul_Kalvem,

If you have any MBDT related questions, please post it in the MBDT community:

https://community.nxp.com/t5/Model-Based-Design-Toolbox-MBDT/bd-p/mbdt

BR, Daniel

[danielmartynek]

Hello Josh,

Please share the code so that I can test it.

Can you elaborate on what the stalled application actually means?

Thank you,

BR, Daniel

[jmap006]

Hi Daniel,

What "stalled application" is referring to is the application has Hard Faulted and is stuck at the Default ISR (infinite loop) waiting for reset.

Attached is a basic application (no SDK), built for S32K144 EVB with the following:

• LPUART1 configured for 115200 bps 8N1 debug console
• Using 8MHz External Clock with PLL enabled, 80 MHz Normal Mode
• Timer using LPIT Channel 0, acts as system tick but with minimum resolution of 1 second
• Linker file with FlexRAM 0x14000000 length 0x1000
• Partition command executing D-Flash 64kB and E-Flash 4kB
• Debug output in place to confirm DEPART, EEERAMSIZE and EEERST codes
• When first partitioned, will write 0xFEEDFACE to EEPROM at 0x14000000
• Every 5 seconds the main application will attempt to write unsigned 32-bit integer to EEPROM at 0x14040000

This application tends to fail at the very 1st write, but will sometimes get success on the 1st write but otherwise fails at the second write attempt. The interesting part is the EEE state machine seems to be  successfully storing the value written to FlexRAM. When opening the Memory tab before and after I reset the MCU, the intended values are shown in memory.

Below output taken from the PE Debug Console:

BusFault: A precise (synchronous) data access error has occurred. 
Possible BusFault location: 0x14000004. 
HardFault: A fault has been escalated to a hard fault.

So I guess the more direct issue (as mentioned above) is a "Bus Fault" has occurred but escalated to a Hard Fault.

Checked optimization level for the build is set to zero (build flag -O0). No change in behavior.

Seems like I have missed some important housekeeping but cannot put my finger on what it may be.

Looking forward to hearing your input.

Regards,

Josh.M.

[danielmartynek]

Hi Josh,

Thank you for all the additional information.

I just briefly tested it with

https://community.nxp.com/t5/S32K-Knowledge-Base/Fault-handling-on-S32K14x/ta-p/1114447

And fails at this operation:

But I haven't found a reason for that yet,

I will update the case once I have the root cause.

BR, Daniel

[danielmartynek · Accepted solution]

Hi Josh,

Please put this loop:

while((FTFC->FCNFG & FTFC_FCNFG_EEERDY_MASK) != FTFC_FCNFG_EEERDY_MASK)
{
}

Before each of these IF statements:

if (eee._word_1 != MAGIC_APP_NUMBER)
if (eee._word_2 == counter)

Thanks,

BR, Daniel

[jmap006]

Hi Daniel,

Thank you for your assistance.

I added in a while loop after the flash and EEE configuration check. Where the MCU waits for EEERDY to assert to '1'.

while ((FTFC->FCNFG & FTFC_FCNFG_EEERDY_MASK) != FTFC_FCNFG_EEERDY_MASK);

I also added the fault exception source code to the EEE test application.

Applying the wait for EEERDY indeed fixed the issue.

Within the s32k144_flash source, I had implementation to use a SETRAM command during configuration. However, this was redundant as the MCU is configured to load the EEE during reset. Therefore, I removed the SETRAM routine in the configuration.

I also implemented the RED LED to turn on during the initialization then turn off once the EEERDY flag has asserted. I found a ~30 millisecond delay to initialize, which includes waiting for the EEERDY flag to assert. See below figure which shows an oscilloscope reading of the RED LED active low on to off time.

~30 millisecond wait for EEERDY + initialization

I would also like to share my final working solution of Emulated EEPROM for the NXP community to reference. When configuring and utilizing the Emulated EEPROM with NO SDK. Please find attached "s32k144_eeeprom_test_v2.zip".

Regards,

Josh.M.

[danielmartynek]

Hi Josh,

The .zip file seems to be invalid.

Can you upload it again?

BR, Daniel

[jmap006]

Hi Daniel,

I have attached the .zip again.

Regards,

Josh.M.