SparkFun Forums

[Hardwareguy]

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

[hsutherl]

HI Hardwareguy,

Your post is the first one I've noticed on Sparkfun about i.mx. I've been thnking about getting an i.mx dev board for several months but have not taken the plunge. I hope you start a trend. Since I don't have an i.mx (and rarely use Eclipse) my questions (no answers) will be on the vague and general side.

• Do you have any way to verify that the code works ok without the debugger?
• Can you load the code and step through it using just the command line version of openOCD, controlled via telnet?
• Can you run gdb from the command line and have it connect to your openOCD session?

There is info on how to connect to gdb on the openOCD web site. If you could get each of those scenarios working with the short code maybe you could begin to zero in on the culprit.

-Hugh

[Hardwareguy]

I triple checked my boot.s and linker files for sanity, and they appeared OK. Looking at the gcc generated srecord file, and .map and .lst files, it all apppears to make sense.

So I set up openocd with telnet, by the way "hsutherl", your ideas were good, because I was thinking of doing more tests like that before I posted this issue. Anyway, I just used openocd without GDB. I did...
> mdw 0x10000000 20 (To see what was there before and after code loaded, I zero'ed it out first)
> load_image myfile.elf (Which resides at 0x10000000)
> step 0x10000000 (To make sure the pc was where I expected)
> resume
The larger size code ran fine. I can tell because my target has a serial port connected to hyper-terminal that displays a message based on key presses. I can see my menu appear, and I can select and run various tests.
This means to me that the larger code is fine, and can run on the target. Something must be wrong with the ARM cross debug part of Eclipse, as to how I am using it. When I halted the above experiment and tried to connect and download the same code with Eclipse (Helios), it no worky. When I commented out some of the code & recompiled, it worked. Perhaps I need to post on an Eclipse CDT website.

[Hardwareguy]

Eclipse appears to be a very useful tool for compiling and debugging. I just don't have enough time to figure out how to set it up, or figure it out what I am doing wrong for my debugging. Every time I think I have my issue fixed, it comes back around and bites me. My code runs great with just openocd, I created a script to run in the telnet session to load and run my code from my working directory. I suspect that the problem could be in GDB (arm-none-eabi-gdb.exe - version 7.2), which Eclipse has to communicate with, or there is some disconnect between Eclipse to the GDB server.

It worked for a while (Or so I thought) when I selected the Mi2 protocol version in the debugger configuration screen. There is also the choice of GDB (DSF) Hardware Debugging Launcher, and Standard GDB launcher. I don't know which one to use, I have tried them both, perhaps neither one is correct.

I now have Eclipse Indigo CDT available, with the GDB plugins. But, I get odd things with Eclipse Helios or Indigo debuggers; Sometimes it appears to load my code fine, so I try to do a single step. It appears to run forever. So I hit the pause button, then a window says 'stepi ignored', and then an error message about "No message received from target". It also reports often, "warning: RMT ERROR : failed to get remote thread list". Sometimes it comes back showing me non-existant source code in the code window, files named 'x', or '0x52738927' (Something like that). I have searched the internet on those messages, but it can take time to scower those sites for what I am looking for, and sometimes there is no answer that I could find that fits my case. The kicker here, is that I probably need to set something that I don't know about (A check box somewhere), and then Eclipse and GDB will work fine. Right now it seems that I could make a career out of this issue.

[Hardwareguy]

Well GDB appears to run my code just fine also. I finally figured out how to load and run it in there.
I can set breakpoints and so on.

So now the issue has to be something in the way Eclipse is interfacing to GDB. At least I can debug my
code if I need to. I am just not a command line typing fan.

[pablooriol]

Hi Hardware guy.
I am working with Eclipse SDK (Version: 3.7.2) - CodeSourcery and Stlink to STM32F4; running on Ubuntu 11.04. I got a similar problem:
I am able to debug. I just have problems when working with breakpoints. I can insert them, but they are not recognized. I mean, when doing resume, execution does not stop on them.
By the way, when loading Debug file I get next warning:
"Warning: RMT ERROR: failed to get remote thread list".
Then, I start debugging. When inserting breakpoint, appears:
"Breakpoint attribute problem: installation failed".
Binary file seems to be well done. I think could be a problem on configuring debugger parameters.
Surfing by the net I saw someone within same problem, saying it is resolved by updating gcc-ubuntu to 7.2. Nevertheless, I am working with arm-none-eabi-gdb version 7.2.50 which is the last one at this time.
Others said gdb was not well configured on Eclipse, I checked it, this is not my case.
Which was the solution you found? After some days fighting against it, I am starting to get quite desperate. :doh:
Thks a lot.
Pablo

[pablooriol]

Hi to all,
Finally I solved the problem by using Standard GDB launcher instead of GDB (DSF). It seems there is a bug on DSF one.