HI all. I am developing a programm with the demo version of the keill compiler.The µ-Controller is a cygnal 8051(c8051f124). I have faced a very strange behavior: int Pack_Counter=0; ... if(Pack_Counter>0){ ...//I set a breakpoint here } when i run the program it sometimes(strange again)stops at the breakpoint.When i watch the value of the variable it is 0 as it should->The Comparison is false->The program should not interrupt. BTW:I have some ISRs but there is none that changes the value of the variable. Does anyone have an idea?
Some weeks ago there was a similar problem: I have an array of 20 bytes.When returning the adress of it from a function i had to realize that some bytes were overwritten by ghosthand. Was this array local to the function or was it global? More information than simply, "Some weeks ago there was a similar problem" would really be helpful. When you had the problem a few weeks ago, what was the solution? Did you solve the problem? Did you find a work-around? All of these thing would really be helpful in finding an answer for you. Jon
Hi all! I have fixed the problem,not knowing exactly what went wrong... But i still ask myself: Did the variable really have the value 0, when the program interrupted at the breakpoint or did the watch window show the wrong value? Are there any known problems with this? BTW: the cygnal has a jtag interface, which enables me to conrtrol the program und read data from the µ-Controller, so it was no simulation which took place. Thanks
"so it was no simulation which took place" but could be a problem in the JTAG interface and/or driver...
I don't usually use the Keil debugger instead of an ICE (Nohau). But at high optimization levels, the Keil optimizer is so aggressive that it wreaks havoc with the ability of the debugger to know which instruction matches which source line. The same instructions or snippets of code get reused for many C source lines. But there's only one "file / line number" assigned to any instruction, apparently the first one where it appears. So Seehau, at least, has fits doing source level debugging. It looks like it jumps to all sorts of irrelevant code, when in fact it's just following the optimized bits as best it can given the information available. As a concrete example, quite a few compilers and debuggers I've used will apparently "jump into" a early if in a procedure when it's the test-and-bail-out sort:
if (bad thing) { // unwind return; } // code presumed safe
"I have fixed the problem,not knowing exactly what went wrong..." If you don't know what exactly was wrong then you probably haven't fixed the problem. Most likely you've changed a bit of code and masked the problem for now, sometime later you'll change another bit of code and the problem will reappear, quite probably in a different part of your program. I find that taking the time to figure out exactly what is causing a strange problem is almost always worthwhile - it'll save you time in the long run. Stefan
In several cases I have seen similar occurrences when using data type variables. Using a Hitex emulator I ahave stepped through assignment of a value to a variable ( register was used by the compiler for the data variable in this case) and the assignment did not work. The variable did not get the value and the register used did not change to the assigned value. Using indirect addressing worked correctly in thes cases so where the problem showed up I am now using idata or xdata variables. It takes more memory and execution time, but at least works correctly