Page 2 of 3
Re: Internal Flash Driver
Posted: Fri Feb 15, 2019 5:18 pm
by faisal
Giovanni, see the attachment. This should give you a head start. It's a working driver for the STM32L4 series based on the hal_flash abstraction.
Re: Internal Flash Driver
Posted: Wed Feb 20, 2019 4:27 pm
by alex31
Hello,
Thanks for this flash driver for the L4
Is it possible for you to send a minimal example that use this library ?
Thanks
Alexandre
Re: Internal Flash Driver
Posted: Wed Feb 20, 2019 8:49 pm
by faisal
alex31 wrote:Hello,
Thanks for this flash driver for the L4
Is it possible for you to send a minimal example that use this library ?
Thanks
Alexandre
Sorry, I don't have one at this time. It should be fairly simple to use - below is an example for erasing.
Code: Select all
STM32Flash flashDevBank2;
stm32FlashObjectInit(&flashDevBank2, 2);
BaseFlash * pFlashDev = getBaseFlash(&flashDevBank1);
// Erasing
while(flashWaitErase(pFlashDev) != FLASH_NO_ERROR) {};
flashStartEraseAll(pFlashDev);
if(flashWaitErase(pFlashDev) != FLASH_NO_ERROR)
{
// handle error
}
As you can see, it uses the hal_flash abstraction. So for programming you would use the flashProgram() function. There is also a flashRead() function in hal_flash ..
If you can put together a simple example - that would help Giovanni integrating it, as an example code would be required in testhal .
Keep in mind the double word alignment requirements the STM32 has for writing to flash if I remember correctly.
Re: Internal Flash Driver
Posted: Sun Apr 07, 2019 10:50 am
by Giovanni
Hi,
In preparation for this I am introducing a proper EFL driver in HAL, implementations will be normal LLD drivers, I will try to transform the L4 code into that. Should not take long.
Giovanni
Re: Internal Flash Driver
Posted: Sun Apr 07, 2019 7:25 pm
by faisal
If you're taking suggestions for the order of including device support, consider the stm32F72x next
Thanks for turning your attention to the internal flash driver. We may have some test/example code to contribute for testhal as well. I'll look into it if it would help.
Re: Internal Flash Driver
Posted: Sat Apr 13, 2019 3:52 pm
by Giovanni
Hi,
I added the new driver to trunk, it is not tested but you are welcome to give it a try
Currently it manages both banks as a single driver instance but I am thinking to modify it to have one instance for each bank like it was in the original proposal.
Giovanni
Re: Internal Flash Driver
Posted: Sun Apr 14, 2019 12:23 pm
by FXCoder
Hi,
First option to try it would be on L4+ but probably 2 weeks before I get to that.
I'll check for differences L4 -> L4+ then and update L4+ .mk etc. accordingly.
Meanwhile, so I can keep up to date with the latest trunk, I added #if (HAL_USE_FLASH) conditionals in hal_flash.c/h and guard in halconf to avoid collision with existing flash driver macro/function names in use on my project.
If you could put those in to trunk it would be helpful.
--
Bob
Re: Internal Flash Driver
Posted: Sun Apr 14, 2019 12:32 pm
by Giovanni
I just committed more changes and a demo EFL+MFS, please work on the latest version.
Giovanni
Re: Internal Flash Driver
Posted: Sun Apr 14, 2019 1:28 pm
by Giovanni
Just a note regarding the flash drivers.
There is this scenario:
- Program flash.
- Power loss results in ECC on read on next boot.
- CPU gets and NMI as result.
Giovanni
Re: Internal Flash Driver
Posted: Sun Apr 14, 2019 1:46 pm
by FXCoder
OK. Noted.
I'm migrating the code to L4+ from F413 and the flash driver is sort of disabled for now.
The flash driver in the F413 version of the project was used to keep log data in internal flash.
I will adopt the new ChibiOS EFL driver system for L4+ as part of the migration and generalization of the code.
It is multi-project so can be built for the L4+, F413, L072 and likely other MCUs.
I found the legacy flash driver (which is still built in the project) collided with ChibiOS hal_flash.h macro flashRead (one extra parameter... offset).
Hence my comment about (HAL_USE_FLASH) conditionals.
I will strip out the old flash driver but just not got to that yet and it didn't break compile until a recent update from trunk was moved into the project.
--
Bob