I'm (again) facing a very strange problem in my project for ARM Cortex-M4 (STM32F301K8). The project requires some of the functions to be executed from RAM (it's actually a bootloader with encryption and option to self-update, but that doesn't matter here). In my startup code I have a loop that "initializes" blocks of data by copying them from flash to given address in RAM. The most common use of this code is to copy .data section and it works flawlessly, because it brain-dead simple.
In my linker script I have something like that:
/* sub-section: data_array */ . = ALIGN(4); __data_array_start = .; PROVIDE(__data_array_start = __data_array_start); LONG(LOADADDR(.data)); LONG(ADDR(.data)); LONG(ADDR(.data) + SIZEOF(.data)); LONG(LOADADDR(.ram_text)); LONG(ADDR(.ram_text)); LONG(ADDR(.ram_text) + SIZEOF(.ram_text)); . = ALIGN(4); __data_array_end = .; PROVIDE(__data_array_end = __data_array_end); /* end of sub-section: data_array */
Then in my startup code I have this code:
// Initialize sections from data_array (including .data) ldr r4, =__data_array_start ldr r5, =__data_array_end 1: cmp r4, r5 // outer loop - addresses from data_array ittte lo ldrlo r1, [r4], #4 // start of source address ldrlo r2, [r4], #4 // start of destination address ldrlo r3, [r4], #4 // end of destination address bhs 3f 2: cmp r2, r3 // inner loop - section initialization ittt lo ldrlo r0, [r1], #4 strlo r0, [r2], #4 blo 2b b 1b // go back to start
Now the problem I'm facing right now is that _ONE_ single word in RAM is not stored correctly... The problem is very strange, because when I have 0x00000000 in RAM and 0x12345678 is loaded in the register (r0 in my case) after the write I have 0x00005678 in RAM... Somehow only "half" of the data is written and the other half in RAM is not modified. This problem happens in the middle of the block - so it's not a problem of wrong range, all the data before and after that problematic spot are copied correctly. This problem happens in the same address (for example now that is 0x20000148), but from time to time the particular address changes. If I just move the block to some different address, the problem just moves to some different spot within this block. If I take another chip, the problem persists but on a different address.
As I wrote above, this is the second time I'm having this issue. Previously I've seen it on STM32F103 and nothing helped on the first day - copying with words, bytes, half-words, double-words, memcpy(). After I went to sleep without solving the issue, the next morning everything worked flawlessly ever since with absolutely no fix - identical code that didn't work on one day worked perfectly fine on the other day...
One guy suggested me that this may have something to do with the Flash Patch and Breakpoint unit in the core, but when I check it with the debugger I see that it is indeed enabled (0x261 in FP_CTRL register), but all the comparators are disabled (0 in FP_COMPx).
Anyone faced this issue and found a reliable solution? Thanks in advance for any hints!
Hi guys,
I am having exactly the same issue with STM32F429 and STM32F427. I wonder if you have found a solution to the problem?
Hello,
did you check the value of r1 (i.e. source code)?
If it would be brought from a pointer of function label, the LSB of its address would be '1'.
Therefore, the copying might be done in un-aligned manner.
I'm sorry if I made the wrong direction.
Best regards,
Yasuhiko Koumoto.
My code is written in C, but I have checked instructions step by step and address values in registers look ok, values under those addresses copied to registers look ok, value in RAM (only one in RAM, under one particular address!) after copying from register to RAM get mutilated. For all other data values, addresses everything works fine.
I have to say that my problem actually _WAS_ caused by breakpoints. When you have a breakpoint in RAM during the copying operation, the symptoms will be as described in the first post. The affected address is the one where the breakpoint was placed.
You are right! I have just checked and turns out that every debugging point I am creating in the part of software that got copied to RAM gets corrupted! Now the question is how to debug it?
I was able to debug my code in RAM - or at least the things I did during the debugging worked correctly. The only issue is that you cannot have a breakpoint placed in RAM when you copy the code from flash to RAM region that has this breakpoint. After the code is copied you can do whatever you want and place as many breakpoints as you like - just not during the flash->RAM transfer.
Thanks freddiechopin! That was very helpful!
View all questions in Cortex-M / M-Profile forum