Closed
Description
Version used: Current HEAD + PR
Affected variant: RemRam v1
Currently I try to write some configuration values with the help of the EEPROM library to the flash.
Given this simple sketch:
#include <EEPROM.h>
void setup() {
Serial.begin(115200);
uint8_t v = EEPROM.read(0);
if (v == 123) {
Serial.println("Saved");
} else {
Serial.println("Wasn't saved");
EEPROM.write(0, 123);
}
}
void loop() {
delay(15);
}
The flash won't safe the variable content. I tracked down the problem to the set_data_to_flash() function in stm32_eeprom.c.
HAL_FLASHEx_Erase(&EraseInitStruct, &SectorError) will return an HAL_ERROR and when debugging the error with HAL_FLASH_GetError(), I will receive a FLASH_ERROR_WRP error (FLASH Write protected error). SectorError contains a 0x17 (23).
Is there anything special I need to do when wanting to write to the flash when using a F7?
Activity
fpistm commentedon Aug 9, 2018
Hi @hasenbanck
You could use the STM32CubeProgrammer to check Write flash protection.
hasenbanck commentedon Aug 9, 2018
I will check the state of the write flash protection this evening when I'm back home. I can't remember having set it though. Could it be set by the factory? Maybe a side effect of using a J-Link programmer? Or maybe it just flipped by chance.
hasenbanck commentedon Aug 9, 2018
I just reset the option bytes and checked the write flash protection. They are not write protected.
One thing is curious: The SectorError points to sector 23, which is the last sector in double bank mode. But since the default (and my) configuration is single bank mode, the last sector should be 11.
Could this be a lead?
Edit: For fun I just edited the FLASH_SECTOR_TOTAL definition from 24 to 12 and changed some broken stuff, which enabled me to save top flash just fine. Either I was simply lucky, or we really select the wrong flash sector number.
fpistm commentedon Aug 9, 2018
Probably there is some issue(s) in the generic definition for F7.
Here:
https://github.com/stm32duino/Arduino_Core_STM32/blob/master/cores/arduino/stm32/stm32_eeprom.h#L54
or here:
https://github.com/stm32duino/Arduino_Core_STM32/blob/master/cores/arduino/stm32/stm32_eeprom.c#L81
FLASH_SECTOR_TOTAL is defined by our CMSIS. Hope It was not wrong :)
I think those part need some deep review.
hasenbanck commentedon Aug 9, 2018
I don't think it's a problem in the generic definition for the F7, since the page size and also the memory addresses seem right.
The CMSIS is not wrong about the total sector count, but only when using the double bank mode. Maybe we shouldn't use the FLASH_SECTOR_TOTAL definition in this case, since 24 is definitely wrong in the standard configuration.
hasenbanck commentedon Aug 10, 2018
Okay, let me structure my thoughts a little bit. As it seems to me right now, the HAL doesn't know how to handle SINGLE / DUAL BANK MODE for the flash. As far as I can see inside the stm32f4xx_hal_flash_ex.h and the CMSIS files of the F76xxx and F77xxx, they used the total value of the flash sectors in dual bank mode.
Information about that mode can be found here.
The stm32f4xx_hal_flash_ex.h and the stm32f7xx_hal_flash_ex.h then use those values to define the available sector, that later the HAL will use in his FLASH module. There we currently haven't defined the sectors for the default 12 sectors in single bank mode.
In my case, the HAL will later try to erase the sector 23 of the flash (last), which of course wouldn't work, since offset and size are different from the sector 11 in single bank mode.
So as a work around, people could activate the two bank mode for the flash on the affected systems, but since you lose easy accessible uniform flash memory, that might not be a good option in the long term.
A better fix would be, to let the HAL become aware of the single / double memory bank configuration of those systems and let the user configure, which mode he wants the HAL to use (with single bank mode as the default, since it's the factory default).
So right now we would need:
fpistm commentedon Aug 10, 2018
Ok looking deeply this and found that it should be possible to know if we are in Single or Dual Bank.
At least for F7:
So F7 HAL provide (if
FLASH_OPTCR_nDBANK
defined):Then it would be possible to know the correct config, something like that.
if Single:
FLASH_DATA_SECTOR --> ((uint32_t)(FLASH_SECTOR_TOTAL/2 - 1))
else /dual/
FLASH_DATA_SECTOR --> ((uint32_t)(FLASH_SECTOR_TOTAL - 1))
For F4 I didn't find any stuff like for F7. I have to check how to handle or if this is planned to add thoses API.
hasenbanck commentedon Aug 10, 2018
Yeah of course, you could read out the option byte and then set the data sector you want to use based on that information. Didn't thought about doing it that way. That would work and wouldn't require a rework on the HAL/CMSIS level.
EEPROM emulation: wrong flash sector used for some F7 variants
EEPROM emulation: wrong flash sector used for some F7 variants
ABOSTM commentedon Feb 13, 2020
Hi @hasenbanck,
After investigations across all STM32 series it is difficult to found a generic way to handle this single/dual bank configuration:
but there are exceptions: ex F42x 1Mbytes single bank 12 sectors; dualbank 20 sectors
In brief this is a nightmare to found a way to management single/dual bank configuration.
As a consequence we propose to keep it simple:
in this case, he must overwrite sector definition thanks to already existing switches: FLASH_BASE_ADDRESS and FLASH_DATA_SECTOR
(see example EEPROM emulation: wrong flash sector used for some F7 variants #938)
You are right, as per F76xxx and F77xxx Reference Manual: https://www.st.com/content/ccc/resource/technical/document/reference_manual/group0/96/8b/0d/ec/16/22/43/71/DM00224583/files/DM00224583.pdf/jcr:content/translations/en.DM00224583.pdf
default configuration is single bank.
But HAL define FLASH_SECTOR_TOTAL doesn't represent the real number of sector but the maximum number of sector (for single and dual bank).
So for variants using F76xx and F77xx chip, we must define FLASH_BASE_ADDRESS and FLASH_DATA_SECTOR according to default sector number.
PR proposed: #938
EEPROM emulation: wrong flash sector used for some F7 variants (#938)
EEPROM emulation: wrong flash sector used for some F7 variants (stm32…