Hello. I´m using an ARM from OLIMEX, the STM32-P103 with a Cortex-M3. I use eclipse to write my code in C, arm-none-eabi-gcc to compile, arm-none-eabi-gdb to debug and OpenOCD to interface the microcontroller trough an ARM-USB-OCD(based on FT2232L), all this in Windows. My program compiles and runs perfect, the problem is when I add a new instruction, it doesn´t mather what instruction and where in my source code, it makes gcc to compile one of my C functions without his return instruction, causing my program to crash when I run it. The two compiled versions of my C function are attached to this post. Here are the last four changing instructions, before and after adding an arbitrary instruction: before: 0x200007c4 <RCC_ADCCLKConfig+56>: add.w r7, r7, #20 ; 0x14 0x200007c8 <RCC_ADCCLKConfig+60>: mov sp, r7 0x200007ca <RCC_ADCCLKConfig+62>: pop {r7} 0x200007cc <RCC_ADCCLKConfig+64>: bx lr after: 0x200007d4 <RCC_ADCCLKConfig+56>: add.w r9, r7, #336860180 ;0x14141414 0x200007d8 <RCC_ADCCLKConfig+60>: lsls r0, r0, #0 0x200007da <RCC_ADCCLKConfig+62>: lsls r4, r3, #0 0x200007dc <RCC_ADCCLKConfig+64>: lsls r1, r3, #0 I think the compiler does something wrong, but I don´t know how adding an arbitrary instruction causes gcc suddenly to compile wrong a function. If someone knows where can be the problem I will be very gratefull. Thanks
From the address, it looks as if this code is located in RAM. And that
your code has stomped all over it!
Generate assembler from the compiler not the debugger. That will show
the code the compiler generated, not the state of the RAM after you
corrupted it. The debugger disassembles whatever is in the memory - good
or bad.
> I think the compiler does something wrong
Occam's razor should be applied here. From the gamut of possibilities,
you are selecting the least likely. The GNU compiler is used
successfully for many millions of lines of code throughout the world. It
is unlikely that you have found a bug that easily that no one else has
spotted, and more likely that your code is flawed.
If you cannot see it, your best bet is to post the code, but you should
be looking at buffer overruns, invalid pointers, and modification of
const data through non-const pointers for example.
Clifford
Thank you. I finally found the problem, I knew that my program fitted into yhe RAM, but the stack is in RAM too, and colided with my code.
Ferdinand Fahlbusch wrote: > Thank you. > > I finally found the problem, I knew that my program fitted into yhe RAM, > but the stack is in RAM too, and colided with my code. ... Ah, yes. Stack overflow, I should have mentioned that too. Stacks grow downward in memory (toward the code in this case).
Please log in before posting. Registration is free and takes only a minute.
Existing account
Do you have a Google/GoogleMail account? No registration required!
Log in with Google account
Log in with Google account
No account? Register here.