- Wed Oct 19, 2011 11:28 am
#134806
I have been successful using on windows XP, Eclipse Helios with yagarto build chain, in compiling C code for my iMX35x target board. I can use the gcc generated elf file to debug in the Eclipse GUI as well. I am also using the flyswatter JTAG tool though USB to the target board. All runs great, I can set breakpoints, step through code, watch variables etc.
Problem:
When I add a few more lines of C code, the size of my compiled code increases from 0x1AA8 to 0x1BB0, it will no longer run in the Eclipse degugger as mentioned above. I am building and loading my code into internal RAM at 0x10000000. There is 128K of internal memory there. My stack pointer is set way up near the top, a long way from 0x1BB0. It may be that some buffer is full, or some data is missing from the elf file above that size. This small of code shouldn't break the bank. I can comment out any of the code in my "C" file (Within reason) to get it to work again. So it doesn't seem to be bad code. It seems to be size. So size does matter.
I cleared the memory from 0x10000000 to 0x10002000 to all 0's, loaded the slightly larger code in, and compared actual target memory contents to the srecord file of the compiled code, and it matches. The code appears to be loading properly, yet Eclipse does not seem to complete the process in setting up the debug session. I also compared the two elf files using arm-none-eabi-readelf.exe, and I see only the code size differences.
I am trying to narrow this down to which part of the system this would fall into. I don't believe it is the compiler. Perhaps there is some variable I have to define somewhere in openocd, gdb, or eclipse?
Any help would be appreciated
Problem:
When I add a few more lines of C code, the size of my compiled code increases from 0x1AA8 to 0x1BB0, it will no longer run in the Eclipse degugger as mentioned above. I am building and loading my code into internal RAM at 0x10000000. There is 128K of internal memory there. My stack pointer is set way up near the top, a long way from 0x1BB0. It may be that some buffer is full, or some data is missing from the elf file above that size. This small of code shouldn't break the bank. I can comment out any of the code in my "C" file (Within reason) to get it to work again. So it doesn't seem to be bad code. It seems to be size. So size does matter.
I cleared the memory from 0x10000000 to 0x10002000 to all 0's, loaded the slightly larger code in, and compared actual target memory contents to the srecord file of the compiled code, and it matches. The code appears to be loading properly, yet Eclipse does not seem to complete the process in setting up the debug session. I also compared the two elf files using arm-none-eabi-readelf.exe, and I see only the code size differences.
I am trying to narrow this down to which part of the system this would fall into. I don't believe it is the compiler. Perhaps there is some variable I have to define somewhere in openocd, gdb, or eclipse?
Any help would be appreciated