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. Regards
EDIT: R_FLASH_LP on S3 devices will follow the same behavior as improved R_FLASH_HP mentioned above.
In reply to Renesas Karol:
In reply to tclong:
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: