stm32duino
STM32F103C8 EEPROM FLASH_BASE_ADDRESS has wrong value
For STM32F103C8 device the FLASH_BASE_ADDRESS in libraries/EEPROM/src/utility/stm32_eeprom.c is calculated as (line 84):
((uint32_t)((FLASH_END + 1) - FLASH_PAGE_SIZE))
where FLASH_END is defined as FLASH_BANK1_END (line 64) which in turn is defined as 0x0801FFFFUL (system/Drivers/CMSIS/Device/ST/STM32F1xx/Include/stm32f103xb.h:574) which is outside of the declared flash size for the STM32F103C8 device which is 64k not 128k.
I guess this works for genuine STM32 chips which usually have 128k despite the declared 64k. I found this issue while using fake CH32F103C8 chips (due to f... COVID 19 genuine stm32 are priced as gold) and those actually have 64k of flash :(
version: Arduino_Core_STM32 current master
HI @mczerski
Yes you're right.
Those definitions are generic and based on CMSIS input for all series. That's why it is possible to redefine all.
You can simply define FLASH_END to the value you want.
You can simply define
FLASH_ENDto the value you want.
Where is best to define this value for a Board/Variant?
You can simply define
FLASH_ENDto the value you want.Where is best to define this value for a Board/Variant?
Variant_*.h
Could this maybe be related to my problem? https://github.com/STMicroelectronics/OpenOCD/issues/23
Could this maybe be related to my problem? STMicroelectronics/OpenOCD#23
No, this issue is related to EEPROM library usage, which emulate an eeprom in flash.
HI @mczerski Yes you're right. Those definitions are generic and based on CMSIS input for all series. That's why it is possible to redefine all. You can simply define
FLASH_ENDto the value you want.
Maybe that's a very basic question, but how should those values be actually calculated? I'm facing probably the same issue now using STM32G030K8T6 and STM32G030C8T6. Committing a value to flash works fine before the RAM memory is filled with other bigger objects. But after all defined objects are initialized and filled with data, commit any value to the flash makes the program crash (overriding the code I guess).
If defining correct values would help, is there any good way to calculate / verifiy them?
Hi @gregbarski
The EEPROM emulation used the latest page of the Flash, for your case:
So only 2k should be used by default. So if your project is lesser that flash size - 2k, it should work if not then you should not use the EEPROM emulation.
@fpistm Thank you. I try to base on the same datasheet.
My device has 31 pages of main memory. I just tried to fix the configuration values for FLASH_PAGE_SIZE, E2END or number of pages with values calculated from the datasheet but with no luck.
The project takes: RAM: [===== ] 50.5% (used 4140 bytes from 8192 bytes) Flash: [===== ] 49.5% (used 32460 bytes from 65536 bytes) so I assume there shouldn't be any problems of overriding the last page.
I'll keep searching.
Right, normally, it should be ok. Did you test eeprom_put anf eeprom_get examples?
Yes, I did. Considering "empty" project, it's possible to write/update each single flash "cell" inside of setup() function. The problem occurs, when program is "fully initialised" and all objects are created. I know it smell like getting out of RAM memory. I've checked it against memory leaks, but it seems fine. So may assumption is, that there is attemption to override the program's memory area. In the same time it seems stupid, as I know that it's being checked by the library code.
@fpistm Is it possible to change the program memory size dynamically when Virtual EEPROM is enabled? It's quite easy for an end user to accidentally add enough code to use the last 2k block, and not know that the Virtual EEPROM will then break.
@fpistm Is it possible to change the program memory size dynamically when Virtual EEPROM is enabled?
No.
Yes, I did. Considering "empty" project, it's possible to write/update each single flash "cell" inside of
setup()function. The problem occurs, when program is "fully initialised" and all objects are created. I know it smell like getting out of RAM memory. I've checked it against memory leaks, but it seems fine. So may assumption is, that there is attemption to override the program's memory area. In the same time it seems stupid, as I know that it's being checked by the library code.
I've tested with a Disco G031 the ut and get examples and it works as expected. My guess is the RAM is too small for your use case.
Thank you for this investigation. I'll be testing it according to this path and will share the results.