What is good practice for using the flash HAL driver?

Karol posted this on Renesas Rulz on 09May2017 regarding problems with leaving the flash driver open:


Karol was addressing a problem where R_BSP_SoftwareDelay() was running slower than expected. He recommends the flash driver be kept open only when actively using it.

In our application we have been opening the driver when the code starts up and we never close it. I'd like to know if I should change that. What, if any, are the other potential issues with leaving this driver open?

For codeflash updates, dynamic open/close can be handled easily because you know when you are starting a codeflash update and when you are done with codeflash update. So you can open the HAL driver at the beginning and close it when you are done.

But dataflash operations use the same driver, and a read/write of dataflash can come at any time. It could be one read/write, or 100 in a row. I understand Karol's comment about using direct memory access for dataflash reads rather than the read() api, but that still leaves dataflash writes to handle.

So my question is, what is good practice for using the flash driver? Can I continue to open it and leave it open forever? Or should I open and close it only when needed? (Which, in the case of dataflash write, means the additional overhead of opening it for every write and then closing it when finished.)

Btw we have dataflash background operation enabled, if that makes a difference. Also, we are using both S5 and S3, so are there differences between the high power and low power driver?

Thanks for any insights.



  • Hello Tom,

    The oddity you referenced (that I documented in another thread) has been addressed with an improvement in SSP 1.5.3 - the R_FLASH_HP driver will now only disable flash cache (if otherwise enabled) for the duration of the P/E sequence.

    One other recommendation is that you use SSP_CRITICAL_SECTION_DEFINE/ENTER/EXIT calls to disable interrupts while performing P/E access to code flash. Moving vector table to RAM alone is not enough since it still references addresses in the code flash. It also goes without saying that if you often rewrite data in the data flash, it may be worth implementing some basic wear-leveling logic to extend lifetime of the flash memory.



    EDIT: R_FLASH_LP on S3 devices will follow the same behavior as improved R_FLASH_HP mentioned above.

  • In reply to Renesas Karol:

    Thank you Karol. Our current S5 application is frozen at SSP 1.5.1, so we are exposed to the potential problem with flash cache that you mentioned. However, I'm not familiar with the flash cache and for that reason I don't think we are using it. If it has to be enabled explicitly, then we have not enabled it. Does using flash cache result in a substantial performance improvement?

    I forgot to mention we are using MMF with two application images and a bootloader. We run flash update to the 'other' half of ROM while continuing to run the application from the 'executing' half. I assume your comments are equally applicable to MMF applications.

    We are indeed using critical sections to protect erase/write operations. And thank you for the reminder about using wear-leveling logic, we did take that into account in our dataflash algorithm.

  • In reply to Renesas Karol:

    This is something I recall and have wanted to ask (thanks, Tom).

    Our code accesses data flash (20 blocks or so, to load parameters) at boot, then is occasional after that. But we have periodic interrupt running at 1 Hz and I think I've seen it run during a flash write and corrupt the data (not repeatable so I'm not positive this happened).

    My dumb questions:
    -what is P/E? Besides price to earnings ratio... 8-)
    -Is there some example code showing usage SSP_CRITICAL_SECTION_DEFINE/ENTER/EXIT ?
    -when I write my boot loader it will run standalone (main code not executing)- so as Tom suggests just open the flash and not worry?
  • P/E is Program/Erase.
  • In reply to tclong:

    Hello Tom,

    Disabling flash cache will negatively affect your performance - flash on S5 devices operates at 40MHz and cache is used to allow CPU to perform instruction fetches at as close to 120MHz as possible. One cache is disabled, each read cycle will take 3 CPU cycles (every access will effectively be a "cache miss"):

    If your project is frozen at SSP 1.5.1, I would consider performing open-close on each access. The overhead will be negligible compared to the performance gain with cache/prefetch enabled.


    Cam, SSP critical sections disable interrupts to prevent preemption for sections that should be uninterruptible. Here's an example of overriding builtin NetX settings inside the critical section:


  • In reply to Renesas Karol:

    Karol, thank you, we will consider performing open-close on each access.