Write to EEEPROM stalls application

cancel
Showing results for 
Search instead for 
Did you mean: 

Write to EEEPROM stalls application

Jump to solution
770 Views
jmap006
Contributor II

 

 

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:

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

 

Tags (3)
0 Kudos
1 Solution
691 Views
danielmartynek
NXP TechSupport
NXP TechSupport

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

View solution in original post

0 Kudos
7 Replies
745 Views
danielmartynek
NXP TechSupport
NXP TechSupport

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

 

0 Kudos
729 Views
jmap006
Contributor II

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.

 

0 Kudos
718 Views
danielmartynek
NXP TechSupport
NXP TechSupport

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:

danielmartynek_0-1626098424508.png

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

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

 

BR, Daniel

692 Views
danielmartynek
NXP TechSupport
NXP TechSupport

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

0 Kudos
635 Views
jmap006
Contributor II

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~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.

 

 

0 Kudos
625 Views
danielmartynek
NXP TechSupport
NXP TechSupport

Hi Josh,

The .zip file seems to be invalid.

Can you upload it again?

 

BR, Daniel

0 Kudos
611 Views
jmap006
Contributor II

Hi Daniel,

I have attached the .zip again.

Regards,

Josh.M.

 

0 Kudos