STM32f105 BLT instruction relocates a local variable - c

Question

Using Keil uVison 4 on Windows 7 I have a c project for stm32f105 that is showing very strange behaviour. I checked it up with a debugger, and after several hours error chasing I localized the error to comming from an already tested in other projects function. Which looked like that:
uint8_t can_add_filter_mask(can_t* this, uint32_t id, uint32_t id_mask, can_frm_type_t type, can_frm_type_t type_mask)
{
CAN_FilterInitTypeDef filt;
/* Empty filter available? */
if(this->filter_len >= 14)
{
return FALSE;
}
/* Select filter number */
if(this->canx == CAN1)
filt.CAN_FilterNumber = this->filter_len + 0;
else
filt.CAN_FilterNumber = this->filter_len + 14;
this->filter_len++;
...
//filt is read
CAN_FilterInit(&filt);
}
It was so that the structure filt is not changed after any of the assigments! Then I changed the dissassembly and it's the following (I'm sorry that it's a bit long):
108: uint8_t can_add_filter_mask(can_t* this, uint32_t id, uint32_t id_mask, can_frm_type_t type, can_frm_type_t type_mask)
0x08001B22 BD70 POP {r4-r6,pc}
109: {
110: CAN_FilterInitTypeDef filt;
111:
112: /* Empty filter available? */
0x08001B24 E92D41FF PUSH {r0-r8,lr}
0x08001B28 4604 MOV r4,r0
0x08001B2A 460D MOV r5,r1
0x08001B2C 4690 MOV r8,r2
0x08001B2E 461E MOV r6,r3
0x08001B30 9F0A LDR r7,[sp,#0x28]
113: if(this->filter_len >= 14)
114: {
0x08001B32 7C20 LDRB r0,[r4,#0x10]
0x08001B34 280E CMP r0,#0x0E
0x08001B36 DB03 BLT 0x08001B40
115: return FALSE;
0x08001B38 2000 MOVS r0,#0x00
151: }
152:
153: /******************************************************************************/
154: void can_clr_filter(can_t* this)
0x08001B3A B004 ADD sp,sp,#0x10
0x08001B3C E8BD81F0 POP {r4-r8,pc}
119: if(this->canx == CAN1)
0x08001B40 4970 LDR r1,[pc,#448] ; #0x08001D04
0x08001B42 6820 LDR r0,[r4,#0x00]
0x08001B44 4288 CMP r0,r1
0x08001B46 D103 BNE 0x08001B50
120: filt.CAN_FilterNumber = this->filter_len + 0;
121: else
0x08001B48 7C20 LDRB r0,[r4,#0x10]
0x08001B4A F88D000A STRB r0,[sp,#0x0A]
0x08001B4E E004 B 0x08001B5A
122: filt.CAN_FilterNumber = this->filter_len + 14;
0x08001B50 7C20 LDRB r0,[r4,#0x10]
0x08001B52 300E ADDS r0,r0,#0x0E
0x08001B54 B2C0 UXTB r0,r0
0x08001B56 F88D000A STRB r0,[sp,#0x0A]
123: this->filter_len++;
124:
125: /* Select mask mode */
0x08001B5A 7C20 LDRB r0,[r4,#0x10]
0x08001B5C 1C40 ADDS r0,r0,#1
0x08001B5E 7420 STRB r0,[r4,#0x10]
I'm not an assembly expert, neither an ARM expert, but I have been programing a bit on assembly and to me it doesn't look bad. What I noticed that was a bit strange was that in between was part of another function can_clr_filter, so it looked like the compiler was reusing some code, though any optimizations are turned off. The interesting part was that when I checked the address of the filt.CAN_FilterNumber variable, it changed after the line
0x08001B36 DB03 BLT 0x08001B40
from address 0x20002262 to address 0x20002252. So all changes were applied just somewhere else in the memory!! The problem has dissapear after I had declared the variable as static, though it's a mistery to me what actually happened... How could it be that a local variable is relocated to another address by the instruction BLT? Or could the uVision debugger show the wrong reference value by watching the &filt.CAN_FilterNumber?

Answer 1

Because you did no post the whole function from this fragment I can only guess:
There are only assignments to the local variable, but it is not used anywhere in your program and it is probably removed from the generated code.
Don't look for errors in the compiler. They are quite good and I have not found any (I am a very active coder). Always when someone says : "this is disassembly listing, the compiler is wrong", the mistake is done somewhere by the asker. Forget about disassembly when you debug your program. You just waste you time.

Answer 2

The problem was in the uVision: http://www.keil.com/support/docs/2824.htm.
uVision is doing some additional optimization so watching local variables is not reliable.