S32K144 EEEPROM - Fighting to get this working

[brucebowling]

I am attempting to enable EEE emulation mode on a S32K144 device (non-SDK). I have reviewed the appnote AN11983 and have searched the forums for this subject and have studied the various example code presented here.

My issue is that I can run the EEE initialization to put the device into EEE mode (checked with DEPART bits in SIM->FCFG1 not equal to 15, and verified with the bits in the FTFC->FCNFG register EEERDY = 1 and RAMRDY = 0 after executing).

However, on a power recycle the device reverts back to non-EEE mode - DEPART becomes 15 and EEERDY = 0 and RAMRDY = 1 ... in other words it reverts back to traditional RAM and not emulated EEPROM. The device "loses" the partition on powerup for some reason. I am not working with any other flash memory operation/operation.

I have told the P&E debugger to not erase the memory range and preserve the data in this range, however on every reload of code the chip is back to being traditional RAM. Same thing with power cycles, the device totally forgets it is in EEE mode and the stored data are lost (I verify this by sending the register contents out over a UART link).

I can single-step the initialization code below in the debugger and see that the chip is partitioned and returning the expected results for EEERDY (=1) and RAMRDY (=0), and the DEPART value becomes 4 - the UART link also returns the same. But cycle the power and the configuration is lost - the values are not "sticking" on a POR.

Here is my code... first, the calling section within main that checks DEPART and calls the EEE Init if device is not in EEE emulation mode:

    // Extract the DEPART value to see if chip is partitioned.
    // A value of 15 means that device is not partitioned....
    depart = (SIM->FCFG1 & SIM_FCFG1_DEPART_MASK) >> SIM_FCFG1_DEPART_SHIFT;    if(depart == 15)
    {
        iEEE = EEE_init();
        depart = (SIM->FCFG1 & SIM_FCFG1_DEPART_MASK) >> SIM_FCFG1_DEPART_SHIFT;
    }

Here is the EEE init function that is called to place the device into EEE mode:

uint32_t EEE_init(void)
{
    // If the RAMRDY bit is zero then this part has been partitioned and the
    // RAM is in EEPROM emulation mode, so no config is needed, just exit.
    if((FTFC->FCNFG & FTFC_FCNFG_RAMRDY_MASK) == 0)
    {
        return(1);
    }

    // Next, the following checks to see if EEERDY flag is high... high means that this silicon has
    // already been partitioned and that we are all ready to go, no need to partition again.
    if(((FTFC->FCNFG & FTFC_FCNFG_EEERDY_MASK) >> FTFC_FCNFG_EEERDY_SHIFT)!= 0U)
    {
        return(2);
    }

    // So, if we get here then we have a brand new fresh silicon chip here that needs to be partitioned to
    // act in EEprom emulation mode, which is RAM that behaves like non-volatile memory.
    FTFC->FCCOB[3] = 0x80;    // FCCOB0: Selects the PGMPART program partition command
    FTFC->FCCOB[2] = 0x00;    // FCCOB1: No CESc operation
    FTFC->FCCOB[1] = 0x00;    // FCCOB2: No CESc operation
    FTFC->FCCOB[0] = 0x00;    // FCCOB3: FlexRAM loaded with valid EEPROM data during reset
    FTFC->FCCOB[7] = 0x02;    // FCCOB4: EEPROM data size: EEESIZE = 2 which is 4kB
    FTFC->FCCOB[6] = 0x04;    // FCCOB5: Flexram partition code - DEPART = 4

    FTFC->FSTAT |= FTFC_FSTAT_CCIF_MASK;    // Fire off the command

    while ((FTFC->FSTAT & FTFC_FSTAT_CCIF_MASK) == 0U);    // wait till done with command

    // Next, configure FlexRAM to act like emulated EEPROM - command code of 0x00 will:
    // - Clear the RAMRDY and EEERDY flags, then
    // - Write all ones to all flexram locations, then
    // - Copy down the existing EEPROM data into FlexRAM, then
    // - Set the EEERDY flag
    // (according to AN11983 the device is already in this mode by default,
    // so this is redundant....)
    FTFC->FCCOB[3] = 0x81;    // FCCOB0: Selects the SETRAM command
    FTFC->FCCOB[2] = 0x00;    // FCCOB1: Make FlexRAM available as emulated EEPROM

    FTFC->FSTAT |= FTFC_FSTAT_CCIF_MASK;    // Fire off the command

    while (((FTFC->FCNFG & FTFC_FCNFG_EEERDY_MASK) >> FTFC_FCNFG_EEERDY_SHIFT) == 0U);    
// wait till EEE is ready

    return(0);
}

I have been struggling with this for a long time without resolution. Any ideas?

- Bruce

[brucebowling]

Yes, I am experiencing the exact same thing, the memory is not preserved and the debugger either crashes or hangs up forever.

One other thing I found out the hard way - you MUST ALWAYS check the EEE state before writing anything to it. Your code implements this check correctly with the statement:

while((FTFC->FSTAT & FTFC_FSTAT_CCIF_MASK) == 0);

This check has to be done for each and every single write, every time, to the EEE. If this check is left out then there can be random code exceptions generated which can be difficult to track down. Sometimes you can "get away" with not performing the check but eventually it may come to bite you later on.

- Bruce

[brucebowling]

Hi Jiri,

Thank you for taking the time to test your code again and showing that it does indeed work. From this I did the following:

1) Grabbed your project and imported into my S32DS tool to run on my custom hardware - no code changes at all. The debugger project was not set up for the external P&E Multilink Universal so I added this as an additional entry.

2) I was able to get your code to load into the board, and I obtained the same results just like you did - It works....

3) I then reloaded my code project back in and the same error (issue) occurs where the partition is blown away. Has to be my code or my setup. So I removed everything in my code not pertaining to this operation and the same error situation.

4) When I set up your new debugger entry, I looked at your old P&E debugger settings. I noticed that there is no Range Preservation enabled, and that the "Emergency Kinetis Device Recovery by Full Chip Erase" was not checked. In my debugger I had these checked - I was following the forum thread presented here where they are shown in this state:

Example: S32K144 EEEPROM usage 

So I unchecked the partitioning and Emergency Device Recovery options in my debugger settings - and now it works! Evidently, following and implementing these old forum threads was the wrong thing to do, at least for my situation.

I also tried working with the "Preserve Partitioning for the device" setting which makes things even worse. I noticed in a previous forum post way back on May 17th (one day shy of a year ago) you submitted a bug ticket to PE Micro regarding this, and it appears it was never fixed - here is the post I am referring to:

https://community.nxp.com/docs/DOC-340625 

So now it works, thanks for the assistance!

- Bruce

[jiri_kral]

Hi Bruce, 

there is an issue with PE Micro debugger. It looks that the backup memory is not preserved and debug session crashes. I already created ticket for that, but PE Micro didn't find any issue a ticket was closed. I'm going to create new one. 

Jiri

[jiri_kral]

Hi Bruce, 

for me it is working fine (please see attached project). On first run - program ends in first while(1) loop: 

after reset ends in second while(1) loop:

Same situation after power cycle when I attach into running program: 

[JackZhang_]

Hi Jiri,

Now,I am using  example 'EEERAM_usage_no_SDK'. l have some questions about it.

Question 1 :When using S32K144 EEPROM ,I need to receive CAN data and UART data simultaneously,but example 'disable  interrupt' wheather means that CAN or UART interrupt should be turn off,if l need to do that. How can l resolve the contradiction between EEPROM storage and real-time receiving data.

Question 2 : According to  'S32K144-RM', I need to use full memory (4K) of EEPROM and I would like to ask how many times I can do full rewrite of 4K data