how to read FlexMemory as EEPROM on s32k144 ?

[建宽高]

hi , how to read  FlexMemory as EEPROM on s32k144 ,

I have read AN11983 , on page  15

```

3.5.2 EEE reads When the EEE is read, the data is supplied by the FlexRAM, so no flash operations are triggered. However, EEE reads are not allowed while a EEE write is in progress. Software must wait for CCIF after a write access before allowing software to continue. This way a special function is needed for EEE writes, but a EEE read does not require any special software. Another advantage to this approach is that no additional delay or flag checking is required if you have multiple EEE read accesses with no EEE write cycles in between. A special case for a EEE read that must be considered is the first access to the EEE after a reset. For the first read of the EEE after reset, the EEERDY bit may need to be tested to make sure that the state machine has completed the initial load of data from the E-flash to the FlexRAM. If the system start-up time is long, this guarantees that the initial data load has time to complete before the first EEE read, then a test of the EEERDY flag before the first read may not be required. However, it is safer to explicitly test the EEERDY bit before the first read access to the EEE. Certain CSEc boot options (for example, MAC boot options) might prevent FCNFG[EEERDY] flag to be set until boot process is finished correctly

```

I know I have to wait for EERDY to read the eeprom,   1 have create   flash_partitioning_s32k144 example on  S32K144 IDE (SDK 0.8.6) ,but not support  such as FLASH_DRV_EEE_READ   API , only support  FLASH_DRV_EEEWrite

I don't know how to read data from eeprom. can you provide a reading api such as FLASH_DRV_EEE_READ  ?

thank you

[1642280511]

Hello, are you Chinese? Can you give me your qq? I have some questions I would like to ask.thank you

[jiri_kral]

Hi, 

you can look at this example - https://community.nxp.com/docs/DOC-340114 

Basically - the current values are loaded after reset - and there is always last value present in your variable mapped into EEERAM space. 

Jiri 

[建宽高]

thanks for your reply

• I want to know if there is EERDY to read the eeprom    API，but the example give write api。

[jiri_kral]

Hi,

there is no such feature - and technically there is no reason for that flag.  Only what you need to do is check readiness for next flash write for example by 

while ((FTFC->FSTAT & FTFC_FSTAT_CCIF_MASK) == 0){}

For what purpose you need something like "Ready for read" flag?  

Normally you have variable like in the mentioned example the struct mapped to flexRAM memory space (0x14000000):

typedef struct
{
float p1;
float p2;
float p3;
float p4;
char ch;
double d1;
double d2;
unsigned long runtime_sec;
int i1;
char user_data[USER_DATA_SIZE];
} eeerom_data_t;

__attribute__ ((section(".eeeprom"))) eeerom_data_t eeerom_data;

After reset - the values  are read from Flash to your struct in FlexRAM . When you change for example 

eeerom_data.i1 to different value - the RAM part is changed instantly and is instantly ready for read. The Backup FLASH part is stored (and ready for another write) when the FTFC_FSTAT_CCIF is set to 1. 

Hope it helps. 

Jiri 

[建宽高]

When I read the eeprom data of the flexram simulation, I wait for the EERDY bit every time. If the pointer points to this area, the data read may be wrong, because there is no EERDY judgment.

If EERDY may not be ready during the eeprom write process of flexram simulation, will there be a problem in reading data in this process, just reading the old data, not reading the newly written data, reading in the process Does it affect the entire system, or is it just that the data is read incorrectly?

thank you for reply

[jiri_kral]

Hi, 

the way how the emulated eeprom works on S32K144 is that you have FlexRAM mirrored to DFLASH. That means for reading there is no way how to get "old" data. In the FlexRAM you always have the last value written there. Interface for you is only the RAM part, the flash backup is done on background. And the only parameter what you need to check is readiness for next write (assign new value to variable in your FlexRAM used as emulated EEPROM). 

It is the same as for normal variable in the RAM - there is no reason check if the variable is updated - it always is. 

Or may be I don't understand what you are trying to do. Please try the example mentioned above. 

Another idea - by EERDY you mean the FTFC->FCNFG register and bit 0 (EEERDY)? This bit is set to 1 when the DFLASH is partitioned as backup for Emulated EEPROM. When device is not partitioned properly - the FlexRAM is used as regular RAM. In this case variables may be uninitialized.

Jiri 

[建宽高]

Maybe there's something wrong with my description

flash_drive.c  has already exist  FLASH_DRV_EEEWrite api. I can use this api to write eeprom, but  flash_drive.c  not provide a read api, like  FLASH_DRV_EEERead api.

I have read AN11983 , on page  15

3.5.2 EEE reads When the EEE is read, the data is supplied by the FlexRAM, so no flash operations are triggered. However, EEE reads are not allowed while a EEE write is in progress. Software must wait for CCIF after a write access before allowing software to continue. This way a special function is needed for EEE writes, but a EEE read does not require any special software. Another advantage to this approach is that no additional delay or flag checking is required if you have multiple EEE read accesses with no EEE write cycles in between. A special case for a EEE read that must be considered is the first access to the EEE after a reset. For the first read of the EEE after reset, the EEERDY bit may need to be tested to make sure that the state machine has completed the initial load of data from the E-flash to the FlexRAM. If the system start-up time is long, this guarantees that the initial data load has time to complete before the first EEE read, then a test of the EEERDY flag before the first read may not be required. However, it is safer to explicitly test the EEERDY bit before the first read access to the EEE. Certain CSEc boot options (for example, MAC boot options) might prevent FCNFG[EEERDY] flag to be set until boot process is finished correctly

I bolded two key considerations

1. However, EEE reads are not allowed while a EEE write is in progress
2. For the first read of the EEE after reset, the EEERDY bit may need to be tested to make sure that the state machine has completed the initial load of data from the E-flash to the FlexRAM

So I wrote the read function based on these two principles in pseudo code

```c

status_t FLASH_DRV_EEERead(const flash_ssd_config_t * pSSDConfig,
uint32_t dest,
uint32_t size,
const uint8_t * pData)
{

   /* Check if EEE is enabled */
   if ((FTFx_FCNFG & FTFx_FCNFG_EEERDY_MASK) == FTFx_FCNFG_EEERDY_MASK)
   {

               /*** Determine if it is writing, if it is writing eeprom, wait for completion*/

              while( writing_flag == 1);

             /** read  operation */

   }

  else

  {

     ret = STATUS_UNSUPPORTED;

  }

return ret

}

```

Is this correct?

[jiri_kral]

Hi, 

finally - I get it. So - the EEERDY flag is set to 1 in meaning that EEEPROM functionality is enabled (Dflash is partitioned for EEEPROM feature). This flag is not cleared when background flash write is performed. If you like to check if the write is done - you can use 

FTFC->FSTAT & FTFC_FSTAT_CCIF_MASK 

When the CCIF bit is cleared- flash operation is performed, when it is set - you can perform another write and you are sure that FlexRAM data are okay and accessible. So - as mentioned in the AN - before first FlexRAM read/write - is good idea check if the Dflash is used for EEEPROM by checking FTFC->FCNFG->EEERDY bit.

It depends on your program architecture - but normally is read more common than write. Good idea is waiting for the CCIF bit in write cycle and perform read without checking this bit (to save CPU time). 

Hope ti helps. 

Jiri 

[建宽高]

That means I can read the value of the eeprom address directly, without judging any flags.

E.g     I want to read the value of the address 0x14000000 to do this?

```c

char read_val=0;

read_val = *((unsigned char *)0x14000000)

```

[jiri_kral]

Hi, 

yes - in case that you will wait for the flag in your write function. Also better idea is map your variables to FlexRAM area by linker file (like in the example above). In this case you can operate with variable name directly -your_flexram_var is located on 0x14000000 address by linker script:

your_flexram_var=100;   - performs backgroud flash write. 

while ((FTFC->FSTAT & FTFC_FSTAT_CCIF_MASK) == 0){}  // don't forget wait for flash write op done; 

your_local_var = your_flexram_var;    - copy value from flexram to your local one - or you can use your_flexram_var as regular variable.  

Jiri

[建宽高]

thank you for your reply:smileylaugh:

[1642280511]

你好，你是中国人吗，能否给我一下你的qq,我有一些问题想请教。

Please use English - we are worldwide community. Thank you. 

Hello, are you Chinese? Can you give me your qq? I have some questions I would like to ask.