2022-06-08 10:24 AM
Hi
I am using Atolic TrueStudio and have some global variables. For some reason one variable is simply updating every time I step through the code with the debugger. I am using a STM32L433 processor and have 56k ram free. The variable is a character and located at 0x20001165 . As soon as the the debugger runs it goes into the below code within startup_stml433xx.s . I have the variable in the expressions so I can see its value, and also looked at the memory location. Every time I step through the below (and any part of the program) the variable just increases by 1. I know no other part of the application is being called. I tried increasing the stack, heap just in case. Also, moved the variable to a different memory location, and even changed its name, but still it increases. Anyone any ideas?
FillZerobss:
movs r3, #0
str r3, [r2], #4
LoopFillZerobss:
ldr r3, = _ebss
cmp r2, r3
bcc FillZerobss
Many Thanks
Scott
Solved! Go to Solution.
2022-06-10 02:33 AM
2022-06-08 10:41 PM
The C language states that global variables are, unless otherwise specified, initialised to zero at startup.
The code you show looks to be doing the work of zeroing global variables. Are you saying this executes every time you start a debugging session (which I expect) or every time you do a single-step in the debugger?
2022-06-09 08:44 AM
Hi
Yes, when I single step through it (or any part of the app) it increases. As this is one of the first thing that is carried out, I dont understand why this is happening..
Scott
2022-06-09 09:53 AM
Is this the primary/only code in the system?
Or is there a loader or some other code that is run first, before this application?
Add "CPSID I" instruction as first thing it does in Reset_Handler
2022-06-09 11:22 AM
Hi
Yes, its the only code in the system, no loader is ran. I have never done assember on the STM32, only 68000 processors. Where would I add this line, and what exactly does this do?
Scott
2022-06-09 12:39 PM
startup.sThe only thing I'd expect to cause a memory location increment is a SysTick driven HAL_IncTick()
2022-06-09 12:55 PM
Hi
Thanks for that, I will give it a try. Thats what I thought regarding SysTick (dont use the HAL), but there is nothing in there that would cause it. In fact, I commented all the info out, and still it incremented.
Cheers
Scott
2022-06-09 01:01 PM
ST HAL as a lot of "weak" linkage code it pulls from who knows where in the absence of code you provide.
The processor and debugger shouldn't have random interrupts, and incrementing words in memory.
From the .MAP try to figure out what memory location that is related too.
Perhaps try different/better tools, and see if it's some manifestation of the tools you're using, because this doesn't sound like an MCU side bug, but some code you're running, or code the debugger is injecting.
Can the MCU print this value/state via a serial port than you can view independently of the debugger and the watch
2022-06-10 02:33 AM
2022-06-12 01:52 AM
Many thanks, that fixed one of the weirdest things I have saw in programming :)