EEPROM Emulation utility fails during "PageTransfer" function (XCUBE-EEPROM V3.0.0 and 4.0.0) on STM32G474 MCU

[MAlam.3]

Hi,

I have incorporated the EEPROM emulation utility in a project based on STM32G474CE MCU. So far the read/write functionality works fine. The problem comes when a page is full and the page transfer function is called. At the end of this function no variables were copied from the "valid" page to the "receive" page. All my variables were lost after page swap.

Upon debugging, i found out that the transfer "for" loop, is trying to read all virtual addresses from 1 to "NO_OF_VARIABLES", and transfer them to the "receive" page. In my case however, there are only 200 variables so NO_OF_VARIABLES = 200, but the virtual addresses are scattered along ranges 0xA000, 0xB000 0xC000 and so on. Therefore, the FOR loop never looks for these variable at all and hence also does not copy them. This looks like a bug to me unless there is something that i am missing or doing wrong. The example application provided with the utility works fine becaue in that aplication, variables are assigned virtual adresses sequentially from 0x0001 onwards so this does not cause a problem for "PageTransfer" function. Logically, according to the refrence manual, there is no limitation or requirement to assign virtual addresses to variables except the values of 0xFFFF and 0x0000. Please provide a solution to this. We are stuck in the middle of a project becaue of this problem.

Here is the code snippet for the FOR loop for transferring variables.

 /* Transfer process: transfer variables from old to the new active page */

 /* First element in receive page can be any one, the following elements are */

 /* ordered from the beginning. */

 /* In case of recovery, Pre-Last element in receive page could be */

 /* corrupted if reset occured during write of this element, */

 /* and last element is dummy value that we have just written. */

 /* Transfer shall then resume from (uhNbWrittenElements-3) variable index */

 for (varidx = (uhNbWrittenElements >= 3U?(uhNbWrittenElements-3U+1U):1U); varidx < NB_OF_VARIABLES+1; varidx++)

 {

  /* Check each variable except the one passed as parameter */

  if (varidx != VirtAddress)

  {

   /* Read the last variable updates */

   status = ReadVariable(varidx, &DataValue);

   if (status == EE_OK)

   {

    /* In case variable corresponding to the virtual address was found */

    /* Transfer the variable to the new active page */

    /* If program operation was failed, a Flash error code is returned */

    #ifdef DUALCORE_FLASH_SHARING

    status = VerifyPagesFullWriteVariable(varidx, DataValue, EE_TRANSFER);

    #else

    status = VerifyPagesFullWriteVariable(varidx, DataValue);

    #endif

    if (status != EE_OK)

    {

     return status;

    }

   }

   else

   {

    if (status != EE_NO_DATA)

    {

     /* In case variable is not found , do nothing */

     /* Any other status is error code occurs during variable read */

     return status;

    }

   }

  }

 }

[Chloe Meunier]

Hello,

"but the virtual addresses are scattered along ranges 0xA000, 0xB000 0xC000 and so on"

I am wondering why you don't assign virtual adresses sequentially from 0x0001 onwards like in the example? You have a particular specification?

XCube-EEPROM uses a flash area to store EEPROM datas from an address defined by user. It has not been developped to store many datas in different addresses.

BR

Chloé

[MAlam.3]

Hi Chloe,

• Because it was not stated anywhere in the Reference Manual that variables should be assigned addresses in a sequential order etc.... or within the range of NO_OF_VARIABLES directive.
• The example shown in the RM also shows only 3 variables but the virtual addresses are like 0x7777 0x0001 etc.
• My application has different set of parameters, and those parameters could increase in future. So i assigned a certain range to a certain set of parameters so that later on if I have to add some variables to a certain set, i'll have room to assign addresses.

Here is a code snippet of how the variable organization looks like.

----------------------------------------------------------------------------------------------------------------------------------

Here is the part that defines the virtual variable ranges

///////////////////////////////////

#define VADDR_0   0xA000   //virtual start address manufacturing parameters

#define VADDR_1   0xB000   //virtual start address configuration settings

#define VADDR_2   0xC000   //virtual start address probes

#define VADDR_3   0xD000   //virtual start address data logging parameters

#define VADDR_4   0xE000   //virtual start address setting options

//////////////////////////////////

Here is the part that assigns the "NO_OF_VARIABLES" directive

///////////////////////////////

#define NB_OF_VARIABLES     200U /*!< Number of variables to handle in eeprom */

//////////////////////////////

and lastly, here is the array that assigns the parameters those virtual addresses..

////////////////////////////////

const Obj_Dict_t Obj_Dict[NUMBER_OF_OBJECTS]=

{

//Communication Profile Specific Area 1000h-1fffh  

 {0x1000,0x00,RO,UI32,2,VADDR_0+0},     //Device Type - M

 {0x1001,0x00,RO,UI08,1,VADDR_0+2},     //Error Register - M

 {0x1002,0x00,RO,UI32,2,VADDR_0+3},     //Man. Status Register - O

 {0x1006,0x00,RO,UI32,2,VADDR_0+5},     //J1939 Device Name(LSB) - O

 {0x1007,0x00,RW,UI32,2,VADDR_0+7},     //J1939 Device Name(MSB) - O

 {0x1008,0x00,RO,STRG,2,VADDR_0+9},     //Man. Device Name(Model) - O

 {0x1009,0x00,RO,STRG,2,VADDR_0+11},     //Man. Hardware Revision - O

 {0x100A,0x00,RO,STRG,2,VADDR_0+13},     //Man. Software Revision - O

//Device Profile Specific Area

 {0x6000,0x00,RW,UI16,1,VADDR_1+0},     //Operating Parameters

 {0x6005,0x00,RO,UI08,1,VADDR_1+1},     //Measure Step Nr.Fields

 {0x6005,0x01,RO,UI32,2,VADDR_1+2},     //Measure Step Position(in nm)

 {0x6005,0x02,RO,UI32,2,VADDR_1+4},     //Measure Step speed(in .01mm)

 {0x6010,0x00,RO,UI08,1,VADDR_1+6},     //Preset Value Nr.Fields

 {0x6010,0x01,RW,SI32,2,VADDR_1+6},     //Preset Value Channel 1

 {0x6020,0x00,RO,UI08,1,VADDR_1+9},     //Position Value Nr.Fields

 {0x6020,0x01,RO,SI32,2,VADDR_1+8},     //Position Value Channel 1

 {0x6020,0x02,RO,SI32,2,VADDR_1+10},     //Position Value Channel 2                                    

 {0x6030,0x00,RO,UI08,1,VADDR_1+12},     //Speed Value Nr.Fields

 {0x6030,0x01,RO,SI16,1,VADDR_1+13},     //Speed Value Channel 1

 {0x6200,0x00,RW,UI16,1,VADDR_0+63},     //TPDO Cyclic Timer (1800)//VADDR_1+14

 {0x6400,0x00,RO,UI08,1,VADDR_1+15},     //Work Area State Nr. Fields

 {0x6400,0x01,RO,UI08,1,VADDR_1+16},     //Work Area State Channel 1

 {0x6401,0x00,RO,UI08,1,VADDR_1+17},     //Work Area Low Nr. Fields

 {0x6401,0x01,RW,SI32,2,VADDR_1+18},     //Work Area Low Channel 1

 {0x6402,0x00,RO,UI08,1,VADDR_1+20},     //Work Area High Nr. Fields

 {0x6402,0x01,RW,SI32,2,VADDR_1+21},     //Work Area High Channel 1

.....

.....

....

////////////////////////////////////////////////////////////////

The total number of parameters which are ever saved to flash is 200. Infact its even less.

[MAlam.3]

and secondly, i understand that variables are stored within a designated range of pages in the flash. The virtual address however is only a tag, to identify a variable. It does not dictate where or how will that variable be written. Is my interpretation wrong?

BR

Asrar

[Chloe Meunier]

Hello,

Sorry I didn't answer before.

Yes virtual address is only a tag. It is used in order to reference a variable. Variables can't be referenced only with their physical address because one variable can be written in multiple addresses depending on the cycling capability. What you describe is to write each variable at a specific physical address but the virtual address won't change the physical address, it is just a tag.

BR

Chloé