2022-04-03 03:35 AM
hello
I have a stm32f030c8t6 which I wish to save some data in its FLASH memory. I use Address Page30 which is 0x08007800 in memory map. it is in 7th Sector. I've developed my code and easily saved some data in that Address. recently I tried to add some lines to my code(note: it is just some lines, for example detect if a is key pressed) but as soon as I add these lines of code, the memory on Page30 Address corrupts!
here is the buffer I tried to save
int32_t flash_buffer_w[DATA_SIZE]={0,0,9999,0,2000,20,280,1200,7000,180,650,850,63,50,3,25,3};
and here is the memory map in debug mode
and here the memory when I added only lines of code(which by the way are executed in certain conditions and in startup these conditions are not happening)
what I have noticed is that: every time that I added one line of code, I monitored the memory. it seems like every time the written code proceeds to the Address which I wish to read and thus I get false saved data(maybe because this is the code data and not my saving data).
so my question is: how could this be possible? I mean I cared about the boundaries and didn't go beyond them. but how can the code violate into FLASH MEMORY Addresses?
here is the memory map in page 33 of stm32f030c8t6 datasheet
2022-04-03 04:02 AM
How big is your code? Seems your write code dont handle errors in write ...
2022-04-03 04:10 AM
this is what I get form .map file
RO=32.15kB
RW=3.52kB
ROM=32.20kB
in datasheet it is said that total FLASH is 64kB and SRAM is 8kB. from above info it is clear that I'm not even close to FLASH and SRAM sizes.
"Seems your write code dont handle errors in write ..."
@MM..1 I don't get what you mean.. maybe explain a little bit?
2022-04-03 04:22 AM
For example every HAL func return HAL_OK or ... You need check.
Second is check memory in debug window isnt perfect way (cached usw) , try read with ST Link utility or programmer.
2022-04-03 07:15 AM
You're trying to save data to 0x08007800, but isn't that addressed used by your code? Your code is more than 32kB 30kB.
2022-04-03 11:21 AM
Are you sure this isn't part of the firmware image.
Will it build if you shrink IROM to 0x7800 in size?
Would it make more sense to push this up to 0x0800F800 so it is out of the way?
2022-04-03 09:32 PM
I always check the return value using HAL_OK
here is my piece of code
if (HAL_FLASH_Program(FLASH_TYPEPROGRAM_WORD, Address, flash_buffer_w[i]) == HAL_OK)
{
Address = Address + 4;
}
for the second part, I know but I think this is the best way for monitoring the memory while it is working
how can I get rid of cash?
2022-04-03 09:37 PM
what do you mean by :"part of the firmware image"
I tried to write/read in 0x0800FC00 Address which is Page63 and it is far enough from occupied memory, but the question still remains:
how can this even happen according to memory map which I attached. according to the memory map, I am using FLASH memory and this has no interfere with the code space, am I right? sure should the code be stored somewhere else right?
2022-04-03 09:39 PM
dear @TDK you are right, but as I have explained for @LT.1edeschi , according to memory map that I've attached, I am using FLASH memory Addresses which should not have any conflict with code Addresses, right?
2022-04-03 10:08 PM
Ahh Ala image on memory map is zoomed code part on right and your 7800h is bad dec 30720 bytes.
You add lines to code and your app is writed on same place as your data = fail error in write and you show HAL%OK , but no else what you do when error ...