Hi,
I've added EFL to L4+ configured for single bank use at the moment.
The use of EFL is for log entries.
The logging application has been adapted for EFL and it is working OK.
Thoughts:
1. Alignment to FLASH_LINE
In efl_lld_program(...) the write address is shifted to ensure correct alignment with FLASH_LINE.
This avoids unintended Flash PGAERR error BUT the calling function is not aware of the address re-alignment and the true address of stored data.
This is problematic when reading back directly from memory (and also using efl_lld_read(...) since it currently does not adjust address).
Would it be better to have a function/macro that aligns an offset to the next FLASH_LINE?
Using functions would then use that to adjust offset to the correct FLASH_LINE alignment before calling efl_lld_program(...).
The calling function then knows the actual address that will be written.
2. Dual bank mode
Would it make sense to have two instances of the ELFD created at runtime when BANKS = 2 and DBANK is set?
The LLD would deal with multiple flash_descriptors as required dynamically.
--
Bob
Internal Flash Driver
- Giovanni
- Site Admin
- Posts: 14444
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1074 times
- Been thanked: 921 times
- Contact:
Re: Internal Flash Driver
Hi,
About point1: The function writes data at the specified offset, it is the line address that is rounded down. The read function should read the data exactly as written, isn't this the case?
About point 2: I made it a single driver because, even if there are two banks, there is a single programming interface so it should have a single "driver state". If you make two driver instances then you could have 2 states and need to synchronize things. Does it allow to program/erase in parallel on two banks?
Giovanni
About point1: The function writes data at the specified offset, it is the line address that is rounded down. The read function should read the data exactly as written, isn't this the case?
About point 2: I made it a single driver because, even if there are two banks, there is a single programming interface so it should have a single "driver state". If you make two driver instances then you could have 2 states and need to synchronize things. Does it allow to program/erase in parallel on two banks?
Giovanni
- FXCoder
- Posts: 384
- Joined: Sun Jun 12, 2016 4:10 am
- Location: Sydney, Australia
- Has thanked: 180 times
- Been thanked: 130 times
Re: Internal Flash Driver
Hi,
Put it down to brain fog on my side (again)...
1. Yes data is correctly addressed and aligned.
2. Read and Write together on separate banks but not write + write.
I guess the question should have been... what are your thoughts on handling Double Bank mode.
e.g. a scenario where flash is running in DBM where it could be that data needs to be written to either/both banks?
That involves two flash_descriptor_t structs describing each bank etc.
--
Bob
Put it down to brain fog on my side (again)...
1. Yes data is correctly addressed and aligned.
2. Read and Write together on separate banks but not write + write.
I guess the question should have been... what are your thoughts on handling Double Bank mode.
e.g. a scenario where flash is running in DBM where it could be that data needs to be written to either/both banks?
That involves two flash_descriptor_t structs describing each bank etc.
--
Bob
- Giovanni
- Site Admin
- Posts: 14444
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1074 times
- Been thanked: 921 times
- Contact:
Re: Internal Flash Driver
Double bank is still a benefit using a single driver instance because the application would not be suspended while writing on the other bank.
What is the benefit in handling it like two instances? there is a lot of added complexity because the required mutual exclusion in accessing the controller.
Giovanni
What is the benefit in handling it like two instances? there is a lot of added complexity because the required mutual exclusion in accessing the controller.
Giovanni
- FXCoder
- Posts: 384
- Joined: Sun Jun 12, 2016 4:10 am
- Location: Sydney, Australia
- Has thanked: 180 times
- Been thanked: 130 times
Re: Internal Flash Driver
Hi,
Sorry for lack of clarity on my part.
Two instances of flash descriptors and flash operation are required within EFLD to dynamically support DBM (i.e. in addition to the descriptor just for SBM).
So I was really just asking how what your thoughts were on the implementation to dynamically support SBM and DBM in EFL.
FYI I'm just in the process of a re-write of this logging application and abstracting it to support both EFL and SPI Flash storage.
Things like the following I want to abstract...
1. using store friendly aligned record offset when creating new records (FLASH_LINE in EFL, various in SPI flash)
2. recovery of old store space for re-use when store is full (Sector Erase for re-use in EFL, Page Erase; Block Erase; Sector Erase for re-use in SPI flash).
3. perhaps wear leveling by using DBM to disperse records across both banks in EFL.
etc.
Anyway hope the question is clear now.
--
Bob
Sorry for lack of clarity on my part.
Two instances of flash descriptors and flash operation are required within EFLD to dynamically support DBM (i.e. in addition to the descriptor just for SBM).
So I was really just asking how what your thoughts were on the implementation to dynamically support SBM and DBM in EFL.
FYI I'm just in the process of a re-write of this logging application and abstracting it to support both EFL and SPI Flash storage.
Things like the following I want to abstract...
1. using store friendly aligned record offset when creating new records (FLASH_LINE in EFL, various in SPI flash)
2. recovery of old store space for re-use when store is full (Sector Erase for re-use in EFL, Page Erase; Block Erase; Sector Erase for re-use in SPI flash).
3. perhaps wear leveling by using DBM to disperse records across both banks in EFL.
etc.
Anyway hope the question is clear now.
--
Bob
- Giovanni
- Site Admin
- Posts: 14444
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1074 times
- Been thanked: 921 times
- Contact:
Re: Internal Flash Driver
Apparently there is a brain fog case also on my side
There is nothing in a single driver instance preventing you to do what you described from what I understood.
About logging, it is something I wanted to add after MFS as a generic module. My idea is to allocate several sectors and use those in a FIFO way, newer log entries would cause the erase of the oldest sector. This would be do wear leveling intrinsically over the allocated sectors. Increasing the number of sectors would not just increase capacity but also reduce wear.
Giovanni
There is nothing in a single driver instance preventing you to do what you described from what I understood.
About logging, it is something I wanted to add after MFS as a generic module. My idea is to allocate several sectors and use those in a FIFO way, newer log entries would cause the erase of the oldest sector. This would be do wear leveling intrinsically over the allocated sectors. Increasing the number of sectors would not just increase capacity but also reduce wear.
Giovanni
- FXCoder
- Posts: 384
- Joined: Sun Jun 12, 2016 4:10 am
- Location: Sydney, Australia
- Has thanked: 180 times
- Been thanked: 130 times
Re: Internal Flash Driver
Hi,
You've pretty much described the logging application as it existed in the legacy code of the Pecan project.
That code used a different flash driver and was quite MCU & application specific.
The logging app is being re-factored (well replaced really) to be configurable for different STMs (multi-board portab.* style) and perhaps be more generic in form.
Regarding EFL driver and DBM...
I just didn't want to start adding to the L4+ variant of hal_efl_lld if this would collide with anything you had planned to do for DBM support.
I'll get to DBM in due course and meanwhile work a bit more on SBM.
--
Bob
You've pretty much described the logging application as it existed in the legacy code of the Pecan project.
That code used a different flash driver and was quite MCU & application specific.
The logging app is being re-factored (well replaced really) to be configurable for different STMs (multi-board portab.* style) and perhaps be more generic in form.
Regarding EFL driver and DBM...
I just didn't want to start adding to the L4+ variant of hal_efl_lld if this would collide with anything you had planned to do for DBM support.
I'll get to DBM in due course and meanwhile work a bit more on SBM.
--
Bob
- Giovanni
- Site Admin
- Posts: 14444
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1074 times
- Been thanked: 921 times
- Contact:
Re: Internal Flash Driver
Just implement it as you see it right, we will discuss details later.
My only point with DBM is that two driver instances would interfere each other because would work on the same internal peripheral. I did DBM for L4 but then removed it because this.
Giovanni
My only point with DBM is that two driver instances would interfere each other because would work on the same internal peripheral. I did DBM for L4 but then removed it because this.
Giovanni
Return to “Development and Feedback”
Who is online
Users browsing this forum: No registered users and 18 guests