STM32 RAM writing issue.

[kalbar666]

Posted on December 15, 2015 at 18:10

Hello,

I am having a bit of a mysterious bug in here. I am working on STM32F427 chip and tryin to write a bootloader. I have a problem with copying memory from FLASH to RAM. Looks like there is a specific memory address in RAM towards which I can't seem to write data properly. If in flash memory I have a value 0x12345678 then after copying it to RAM I get 0xXXXX5678 (XXXX- random stuff that was already in RAM). This is happening only in this one particular region and it doesn't help at all what kind of pointers I am using to write to it (uint8_t*, uint32_t*). I have even tried creating a temporary value in RAM and copying to the problematic memory region and the same problem appeared. Memory sections seem to be aligned in linker script (. = ALIGN(4);) and memory addresses coming out of it used in copying seem to be aligned as well. The weird thing is that I can move the whole RAM memory in linker from 0x20000000 to 0x20000200 and the problem is moving to the same address related to the beginning of RAM. I have replicated the same problem on the STM32F429 Discovery board with the same code. I have found two other threads with exactly the same issue but with no answers. https://community.arm.com/thread/8464 https://my.st.com/public/STe2ecommunities/mcu/Lists/stm81/Flat.aspx?RootFolder=https%3a%2f%2fmy.st.com%2fpublic%2fSTe2ecommunities%2fmcu%2fLists%2fstm81%2fMemory%20issue%20on%20STM8L151G6&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580001E3853D9DB932A46A3FE4CD15CAB46FB&currentviews=236 I am bit stuck over here and any help will be apprieciated. #stm32-ram

[kalbar666]

Posted on December 16, 2015 at 16:25

Little bit more testing and it turns out that if my main() function has as a first thing to do to jump to other function (like HAL_Init() in my case), then temporary breakpoint placed by debugger is completely meesing up the jump instruction on assembly level and chip is trying to jump completely outside of its memory map (0x1FFFXXXX) causing a crash. For other breakpoints somewhere further down the code things are working fine, I mean code in RAM gets changed by debugger, but resolves properly as dubuger properly places and handles its breakpoints. Solution for me turns out to be placing first breakpoint in startup assembly code at the line where jump is about to happen to main function, and then stay away with breakpoints on the first line in main function.