Data flash memory is erasing occassionally

Hi Renesas team,

I am using rl78 r5f102aa microcontroller and its data flash to store some settings in it.

In my product I am using 3.7v battery backup (2400mah), when power interruption happens, the mcu should run with battery backup.

Now, the problem is, the stored settings in data flash is erasing sometimes. I thought the issue is because of the writing/reading happens during battery powered. So I stopped memory operations during power interruption (battery time). Still the same issue observed.

Now, I started writing the settings in two different banks in data flash as extra data backup. I am not sure whether it will resolve the issue.

I want to know the reason for erasing and if the erase happens, will it erase complete data flash (second block) too, which I am using as extra second back up.

Please suggest.



  • Good day, manju!

    How are things going for you? Have you observed when this likely to happen or it just happened randomly? I hope you could wait for responses from the experts on RL78. Thank you.

    Best regards,
    RenesasRulz Forum Moderator
  • In reply to Sai:

    Hi Sai,

    Thanks for the response.

    The issue is observed randomly - weekly/monthly once. I am reading the dataflash stored parameters at the beginning of the main function after the peripherals and dataflash initialization.

  • In reply to manju:

    The data-flash cannot be erased without initiating a self-programming operation on the block. Are you using the Tiny / T02 EEL or just FDL in your code? EEL is designed to be reset resistant and implement wear-leveling. If using only FDL you must implement your own strategy for both concepts to maintain data integrity.

  • Thanks for the response.

    I am using FDL library and the following APIs

    1. For write operation

    a. R_FDL_Open()
    b. 5 secs delay
    c. If (R_FDL_Erase() == PFDL_OK)
    d. 5 secs delay
    e. If (R_FDL_Write() == PFDL_OK)
    f. 5 secs delay
    g. R_FDL_Close()

    2. For read operation

    a. R_FDL_Open()
    b. 2 secs delay
    c. R_FDL_Read()
    d. 2 secs delay
    e. R_FDL_Close()

    During reading operation, i am not checking return result of R_FDL_Read() and during write operation, executing write function only when I get the return as PFDL_OK from erase function.

    Here am not using R_FDL_Create() and black check functions.

    Now I think I have to implement reset resistant and wear leveling as per your suggestion. I am not understanding this. Please eloberate and guide me how to implement those.

  • In reply to manju:

    Do you have the documentation for the Renesas FDL and the EEL?

    The users manual for the FDL shows examples of how to use the FDL, I don't understand why you would be executing fixed timing delays, when the library can notify you of the completion of the operation.  For some reason, I don't see the RL78/G12 flash programming times specified in the documentation.  But for other devices which use the same flash process, a block erase operation takes 5ms while a write operation takes 10us.

    Example code for the T02/Tiny FDL can be found in section 4.7 of the FDL U/M R01US0061ED.  The library can be polled for busy status, calling the handler while busy.

    Note that the RL78 data-flash is not like byte-erasable EEPROM.  The erase block size is 1KB while a write unit is 1-byte.  The EEPROM Emulation Library (EEL) uses an approach to implement wear-leveling by performing multiple write operations in a single block, before an erase operation is required.  Reset resistance means that a specific flow is used to ensure the data integrity (e.g. a start marker is first written, followed by the data, followed by an end marker).  Reset resistance also ensures that data is not lost during a block erase operation by duplicating the data in another block before the erase operation is done (Renesas EEL refers to this concept as a "refresh" operation).

    Please refer to the T02/Tiny EEL U/M for more information on the wear-leveling techniques and reset resistant features of the Renesas EEL.

    I would not generally recommend that a user implement their own EEPROM emulation unless they are a very experienced programmer.  If your application has the memory resources available to use the Renesas EEL I would highly recommend that you consider using this off the shelf library.

  • Thanks JB.

    I observed the issue is occurring during erase operation only and voltage drop happening during the same.
    I cannot use eel library as I dont have sufficient memory space.

    I gone through section "2.6 Abortion of commands" in the manual you referred. The function fdl_abort() aborts erase command if the handler is busy and this can be used during voltage drop during erase operation in order to avoid reset of MCU.

    But in FDL library, there is no abort API. Can I implement this function in the FDL erase API so that I want to use abort feature if the erase handler is busy.

    Kindly suggest.

  • In reply to manju:

    Can you please elaborate on the statement, "But in FDL library, there is no abort API."? If you are using the "Tiny" / T02 FDL this command exists. Or are you using the "Pico" / T04 FDL type? The Pico FDL does not support the abort command.

    Please refer to the Data Flash Access LibraryType T04 (Pico), European Release for the Pico / T04 FDL U/M.

    Perhaps your battery is not able to sustain the power required to perform the erase operation?  If the abort needs to be supported you would have to use the Tiny / T02 FDL.

  • In reply to JB:

    Yes, my power supply sometimes, not able to sustain the power required to perform erase operation, but it is too occassionally happening. Is this possible to implement abort API in Pico / T04 FDL?
  • In reply to manju:

    If you must have the abort feature, you will have to update to the Tiny / T02 FDL. Additional RAM resources are minimal (about 10-extra bytes of stack space), additional code space is about 400-bytes.
  • In reply to JB:

    Thanks JB.

    I found the tiny / t02 fdl library and started integrating into my code. One more doubt is, I have middle layer for pico fdl library which is generated one. (r_cg_pfdl.c and .h) - CS+ CC-RL

    Do we have middle layer for tiny t02 fdl also? How can I get it? Please elaborate the steps if it tool generates..

  • In reply to manju:

    Files named "r_cg_*.c,h" are typically code-generated files from the Renesas Applilet, for your G12 device this is the Applilet3 (latest version is 1.18.00):

    Unfortunately it appears that only the Pico / T04 data-flash library is supported by the Applilet tool.  In this case you would need to manually edit the middle layer to support the Tiny / T02 library, or remove that layer altogether.

  • In reply to JB:

    Thanks JB.

    I wrote the middle layer for Tiny / T02 data flash library. Everything works fine and need to check the unexpected erase happens or not for 1 week or more.

    I implemented abort feature in the erase API as below.

    if (gFdlStatus == 1) // if FDL_Open() executed
    gFdlReq.index_u16 = blockno;
    gFdlReq.command_enu = FDL_CMD_ERASE_BLOCK;
    /* Wait for completing command */
    while(gFdlReq.status_enu == FDL_BUSY)
    auto int count = 0;

    FDL_Handler(); /* The process for confirming end */
    if(gFdlReq.status_enu == FDL_BUSY)
    if(count >= 2)
    if(FDL_Abort() == FDL_OK)

    Abort API will execute only if FDL_Handler returns BUSY second time also. As per my understanding, the restart of MCU and data flash erase is happening because the erase command execution is taking more time and completing after giving multiple FDL_BUSY returns. In this time, as I am running the microcontroller using battery, the power is not sufficient and voltage drop happens, which leads to reset of MCU. Now because of abort execution before multiple FDL_BUSY returns, it will abort the commands executing and I will update the memory after sometime.

    Kindly go through the code and give me your valuable suggestions.
  • In reply to manju:

    I don't really understand the logic in your code, the handler is going to have to be called many times for the erase operation to complete, aborting after only two calls doesn't make sense to me.

    If you look at section 5.2.2. of the Tiny FDL U/M, you will see the command execution times, and the erase can be ~5.8ms typical to over 265ms max.

    To be honest my experience with the automotive RL78 devices (F1x), which typically have a battery voltage monitor circuit with a small reserve power and can be triggered by falling voltage to take action before the reserve runs out. 

    Are you using the LVD to ensure proper operation of the device?  If you battery is unable to provide the required power to program the data-flash, I'm not sure what you can do if anything until the battery is refreshed, so maybe a simple reset would make sense, or at least an interrupt for the device to take some action.