1. Home
  2. Embedded Programming
  3. Problems with Keil debugger vs. Forth

Problems with Keil debugger vs. Forth

I am working on an entry for the Luminary Micro Stellaris design contest. The contest rules require you to use the the Keil tools that come with the LM eval board. This limits the entries to C programs. I started with a Forth program and converted it to C. This went without too much trouble and the conversion was fairly easy. I did find it a bit harder to debug under C using a standard debugger, but there were not many issues that could not be resolved without too much pain. Mainly it was a lot easier in Forth to test each word or routine separately rather than as part of a whole. The C debug tools just don't make it easy to test routines separately.

The real trouble began when I started writing new code in C that was somewhat real time. As I used the debugger it became apparent that this was not going to be so easy. Since the routines had to be tested as part of the whole, I had to let the interrupts run, so I was never too sure of the state of the environment while I was debugging. Still, I didn't have any major problems until I noticed something odd.

I was using the "Locals" watch window for most of the variables since this was automatic. But once in awhile some of the local variables would seem to take on absurd values. I could not find anything in my code that was doing it. I dug into the disassembly listing and found that local variables and the parameter passing was being done in registers rather than on the stack. So when another routine was called, the variables were moved to other registers to free up the standard parameter regs. At this point the debugger would lose track and report the new value in the old register as the variable that had been moved to the new register. I could use a standard watch window to show the correct value, but this was a PITA since every routine had its own copy of this variable and I would have to type it in again when exiting or entering another routine. This is a pretty major bug in the Keil tools in my opinion. I don't know if this is limited to the ARM or the CM3 or if it is common to their combined ARM and Keil tool set.

I also found that in at least one case a local variable could not be monitored at all! It did not show up in the "Locals" window and I could not add it to a regular watch window. This was not possible to work around without changing the code and made a tricky bug very, very hard to find.

All in all I am not a fan of the Keil tools at this point and I don't think I am very happy with embedded C development. I have done tons of embedded development in the past and I never realized how limited the tools were. I always thought of the problem as being an unavoidable part of the development process. Factoring code to small routines and testing them interactively is so much easier to debug and in Forth is so much easier to write.

Am I the only one to have trouble with the Keil tools? Am I working with an old release? This is the version directly off the eval board CD.

The contest rules say the submission has to be done using the Keil tools. But that does not mean I have to use the tools while I am debugging. I have access to the IAR tools, but I don't know that the eval board is supported with these tools. Anyone know if there is a board support library for the LM3S811 eval board under IAR?

Reply to
rickman
Loading thread data ...

That sounds inefficent..

Sounds to me like a std issue, where the relatively flat-scope of the debugger, is simply unable to keep up with the compiler gymnastics. Likely to me more of a problem, on a processor without direct memory opcodes, as it does have to juggle the registers.

Have you tried different compiler settings ?

Most debuggers I've used have some sort of lifetime / interrupt interaction at the detailed level - the only time you can truly trust them, is when the debug kernal is not active :)

- so if I'm looking for a specific bug, I'll use breakpoints over single stepping, for example. (or the simulator, depends on the bug; Sim/debug often have large amounts of common code/mindsets, so in your specific problem, I'd guess the Sim does the same thing )

You can also create trace-memory yourself, where you write operation tags/trace values - yes, a pain as it is another step, but it does remove the unknowns of the debug portion.

An interesting restriction. Have you asked them just why that is imposed ?

It would be more widely informative, if your contest entry could be made as both the forth version, and the forth-to-C version, with porting comments.

Did your forth version get fully debugged ?

-jg

Reply to
Jim Granville

...snip...

Yeah, I figured as much, but I also figured that they would have had this worked out at this point... unless this is an integration issue with marrying the Keil debugger with the ARM compiler or something similar.

I am on the lowest optimization setting and I can't find much else. If I had manuals, I guess I could go through them, but the help is pretty inefficient and the machine I am working on is not web enabled. I think they provide manuals online.

I had hoped to use a break on something concerning the variable rather than just a line of code. But I don't see that as a feature. I have not done this level of debug with ARMs before, so I don't know how much is the tool vs. ARM vs. CM3.

I may give the sim a try. I don't know if they model the user interface of the board or not. It shouldn't be too hard to do, but with the bugs they have, I don't expect a lot of frills.

Yes, very much a PITA. I managed to solve my problems. I just want to find out where the problems with the tools are. I need to get code to drive my hardware testing and this is the sort of thing I can use to justify getting a Forth tool in place of an expensive compiler/ debugger combination.

imposed ?

I would be happy to do that if there was a way to use Forth on the final board. But there are a number of library routines without source for the peripherals and I don't know of a Forth for the CM3 MCUs just yet.

Yes, it runs fine on my desktop. It is just the processing core of my entry without a user interface. Or in other terms, with the Forth consol as the user interface. The target is a lot more crude with only a pot and a single push button for input and a 16x96 OLED display as output. My only real triumph in this design is that I managed to make this interface work with a menu structure. The app itself is no big deal.

Reply to
rickman

It is just the processing core of my

How about the serial port? I do much of the debugging with the serial port. I also drive my target system with it.

Reply to
linnix

This is completely normal. The procedure call standard actually specifies that argument/result/scratch registers.

On something like x86 usually everything goes via the stack however most major procedure call standards for it also allow passing arguments via registers. MS call this FASTCALL and it doesn't really have name under GCC but is just attribute which can be applied to a function via a GCC language extension.

I don't quite see what you are getting at here, are you saying that you inspecting the value in a register window or in a locals window? Are you stepping at source level or instruction by instruction? If you are stepping through function prologues and epilogues at machine code level you can't expect the debugger to show the correct values until you've actually stepped into the new function.

Again I don't understand is this a local automatic variable to the function or has the conversion from forth created a load of variables at global scope or something? Or is it a parameter to the function which you are manipulating?

If it actually is showing the wrong value for a local then this is a debug illusion problem and please file a bug.

Are you sure the variable had not been optimised away? Specifing any optimisation may impair the debug view, this is minimised at -O0 and -O1 will give a fairly good debug view.

I think that you are just expecting far too much from a C debugger. You can not compare a language where you are patching words into a runtime where the debugger is essentially part of that runtime to a statically compiled language where the debugger must essentially undo the compilation with the help of debug information.

-p

--
"Unix is user friendly, it's just picky about who its friends are."
 - Anonymous
--------------------------------------------------------------------
Reply to
Paul Gotch

Yes, I was not speculating that this was abnormal. I was just setting the scene for the issue.

here, are you saying that you

I was single stepping at the source level and watching the "Locals" pane of the "watch" window. Of course the register window was always correct, but I would have to view the disassembly window to figure out what the registers meant. I don't know ARM assembly enough to understand the details there, but I could tell when data was being moved to setup a call.

Nothing special was done in the conversion. I just used a parameter list instead of explicitly setting up parameters on the stack. Of course the rest of the code was simpler since I could eliminate the stack manipulation. The locals I am talking about are just that, the variables I declared local to the routine being debugged.

Yeah, the question is, does the Keil debugger have this problem with other targets, or just the Stellaris parts? I did a little searching for an errata list for the tools and couldn't find one. But then I didn't spend a lot of time looking.

No, but the optimization was at level 0 which is supposed to be the least. Pretty strange to do that much optimization at level 0. Also, I don't think the variable could be optimized out without some significant deviations between the source and the assembly. This dichotomy did not appear to exist. I'll see if I can find a point of contact with Luminary or Keil to discuss these issues.

Yes, I believe that is what I said. Forth seems to debug more easily.

I recall using a tool a long time ago that provided a command line where you could invoke any routine with parameters somewhat like a Forth command line. I don't recall the tool, but it would seem this has not caught on. I do remember it was a lot of typing.

Reply to
rickman

... snip ...

DDTZ provided such a command. See:

--
Some informative links:
  
  
  
    (taming google)
    (newusers)
Reply to
CBFalconer

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.