-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cpu: stm32l1: add flashpage writing support #7712
Conversation
Can maybe @haukepetersen or @vincent-d take a look on this one? @kaspar030 ping! |
This will also be affected by #7667 |
Yes indeed, let's reach consensus there for a good solution and I'll implement it here. |
cpu/stm32l1/include/cpu_conf.h
Outdated
* @{ | ||
*/ | ||
#define FLASHPAGE_SIZE (256U) | ||
#define FLASHPAGE_NUMOF (2048U) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is off: I am pretty sure the flash has not the same size for all members of the stm32l1
family -> these values have to be guarded with the actual CPU_MODEL_xx
values.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
True, will fix.
|
||
/* If the erase operation is completed, disable the ERASE and PROG bits */ | ||
DEBUG("[flashpage] erase: resetting the page erase and prog bit\n"); | ||
FLASH->PECR &= (uint32_t)(~FLASH_PECR_PROG); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hm, are you sure about this one? You also disable it in line 168, and shouldn't it only be done there, after you have (potentially) written to flash?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oops, a leftover of a test, will remove.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is working like that, since the program bit apparently only affects when erasing the flash.
Comments addressed. Ping @haukepetersen, maybe @vincent-d or @aabadie can also take a look? |
Ping. |
6f8052a
to
5ee33ee
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor nits regarding doxygen
cpu/stm32l1/include/cpu_conf.h
Outdated
@@ -72,6 +72,20 @@ extern "C" { | |||
#define CPU_FLASH_BASE FLASH_BASE | |||
/** @} */ | |||
|
|||
/** | |||
* @brief Flash page configuration |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should be @name
and also add a closing line /** @} */
after the defines.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
cpu/stm32l1/include/cpu_conf.h
Outdated
* @{ | ||
*/ | ||
#if defined(CPU_MODEL_STM32L152RE) | ||
#define FLASHPAGE_SIZE (256U) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
these define are not self doxygen documented
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are these required? I don't see any example in other CPUs...
a4eb2a6
to
7c4df29
Compare
7c4df29
to
4031cff
Compare
No more waiting for PR. @aabadie are your concerns addressed? |
ping @aabadie |
I forgot this PR when I worked on #8768. Looking at this PR again and comparing with #8768, I see several issues:
|
The code for stm32l is actually very different from other stm32 variants. I didn't copy/pasted any code for this.
Indeed, these functions were added to avoid code duplication in this implementation while adding
This can be discussed, writing into EEPROM might need another kind of driver since it's not a flash memory (as the name indicates), thus another API for EEPROM is needed IMHO. |
Indeed, but the workflow is the same between variants and can for sure be factorized using preprocessor macros. See #8768, where the code is better factorized IMHO.
Yes, but it's an extra feature. The order, before this PR or after, is not very important, since it can be applied to all variants of STMs that already have flashpage (stm32f1). Now that I'm thinking of it, this addition (and the _lock/_unlock) should have been done in a preliminary PR.
Not sure about this. My reading on wikipedia states that Flash memory is a kind of EEPROM
I'm not sure about that. I was more thinking of extending the flashpage API (starting by simply renaming the module |
I'm actually working on this extension for stm32f1, which is the only one so far tested.
Without flashpage_write_raw, these functions have no use, so I don't see the need to PR them before.
Which doesn't mean that EEPROM is a kind of flash, data EEPROM in these chips is not divided by pages, which IMHO is out of the scope of this driver.
Read and write EEPROM can be abstracted to not only create an API for chips which have it internally, but also for chips which can be attached through I2C or SPI. I see very complicated to merge everything in one |
Now that #8768 is merged, we can merge this one. |
Just added flashpage write support for stm32l1 cpu's, which can be tested with tests/periph_flashpage.