I am debugging and looking at code generated by the C compiler (for a Silabs 8051F312) and I am seeing it go to the middle of code in breaking from a case statement. Of course its infuriating ... so I suspected that it was the code optimizer but no, it really completely subverted my logic. Where do I do to follow its bad logic and pinpoint the problem. The .lst doesn't help since its shows the code all nested fine. I was thinking the line files are screwed up but recompiling it gets the same results. The assembly code, clearly shows the jump into the middle of code shown in the line files. HELP??? :)Rik
Are you sure there's actually something wrong with the flow of execution? You might want to post both the C source and compiler output. (Note the pre and /pre tags.) A source-level debugger can often be confused by highly optimized code. One line of C may correspond to many lines of assembler. When the optimizer is done, some of those lines of assembler may be shared with many lines of C. But the debugger chooses exactly one source line to show for any given address. Thus, the source window can hop about strangely. Code for entry and exit (whether for procedures, or cases in a switch) often winds up being shared. Does your program flow correctly if you switch to the assembler view and single-step through it?
Have you tried just reducing the optimisation level to the minimum? I find that 'case' statements are often particularly "badly" affected by optimisation (that is "badly" in the sense of "hard for source-level debugging" - it's very good in the sense of run-time efficiency...!)
thank you much. I am always appreciative of code optimization and figured that is what happened unfortunately in this event, it did not generate properly. The assembler has clear labels (merged with the c code) and it is clearly going there in the listing and the debugger. CPU is behaving as shown. thansk. :)r
View all questions in Keil forum