Nina G. <nospam@nospam> wrote:
> I am debugging a program in C for Chipcon 2430 processor in IAR Embedded
> Workbench. When I run the program step by step, I observe that the execution
> cursor jumps over some instructions and they never get executed. What could
> be the reason for this? A memory mapping issue? Stack corruption?

I don't know that this is the case for your particular CPU, but another
possible issue is the "Branch delay slot" on some CPUs.

Just before executing a branch, the instruction immediately after it
also executes.  If that happens, you might not see it in your debugger.

Just my .002 cents / kilobyte.

--buddy

Nina G. wrote:
> "larwe" <zwsdotcom@gmail.com> wrote in message
> news:1165796097.806372.208120@73g2000cwn.googlegroups.com...
>>> I am debugging a program in C for Chipcon 2430 processor in IAR Embedded
>> ... which is an 8051, n'est-ce pas?
> Yes.
> 
>>> Workbench. When I run the program step by step, I observe that the
> execution
>>> cursor jumps over some instructions and they never get executed. What
> could
>> Are you sure they never get executed? Since you are programming in C,
>> single-stepping the program might mean single-stepping through the
>> SOURCE line-by-line, which is not the same thing as single-stepping the
>> assembly output.
>>
> The debugger provides a panel with the assembly code. I observe that no
> assembly output is generated for the skipped lines.
> 
> Thank you,
> 
> Nina
> 
> 
Look at the code.  Do nothing code gets removed during optimization.
Redundant code gets combined.  Single -stepping optimized code can be 
confusing sometimes.

Nina G. wrote:

> The debugger provides a panel with the assembly code. I observe that no
> assembly output is generated for the skipped lines.

Then there is nothing to single-step for the skipped lines. They are
presumably #define'd out or consist of macros that do nothing.

Thank you, this helped.

Amazingly, the optimization was one of the first things I was about to check
but then it escaped me...

Thank you,

Nina

"FreeRTOS.org" <non.given@hotmail.con> wrote in message
news:ww9fh.14731$k74.11475@text.news.blueyonder.co.uk...
>
>
>
> "Nina G." <nospam@nospam> wrote in message
> news:newscache$i2y2aj$bw8$1@news.actcom.co.il...
> >I am debugging a program in C for Chipcon 2430 processor in IAR Embedded
> > Workbench. When I run the program step by step, I observe that the
> > execution
> > cursor jumps over some instructions and they never get executed. What
> > could
> > be the reason for this? A memory mapping issue? Stack corruption?
>
> Do you have optimisation set to 'none'?  Even when this is the case I have
> seen the IAR compiler remove obsolete code.  Also the chipcon libraries
> #define the same name to many different things depending on other
> definitions making it difficult to see exactly what should be executed.
> Some definitions are null so will not generate code.
>
> Regards,
> Richard.
>
> + http://www.FreeRTOS.org
> + http://www.SafeRTOS.com
> for Cortex-M3, ARM7, ARM9, HCS12, H8S, MSP430
> Microblaze, Coldfire, AVR, x86, 8051, PIC24 & dsPIC
>
>

"Nina G." <nospam@nospam> wrote in message 
news:newscache$i2y2aj$bw8$1@news.actcom.co.il...
>I am debugging a program in C for Chipcon 2430 processor in IAR Embedded
> Workbench. When I run the program step by step, I observe that the 
> execution
> cursor jumps over some instructions and they never get executed. What 
> could
> be the reason for this? A memory mapping issue? Stack corruption?

Do you have optimisation set to 'none'?  Even when this is the case I have 
seen the IAR compiler remove obsolete code.  Also the chipcon libraries 
#define the same name to many different things depending on other 
definitions making it difficult to see exactly what should be executed. 
Some definitions are null so will not generate code.

Regards,
Richard.

+ http://www.FreeRTOS.org
+ http://www.SafeRTOS.com
for Cortex-M3, ARM7, ARM9, HCS12, H8S, MSP430
Microblaze, Coldfire, AVR, x86, 8051, PIC24 & dsPIC

"Jim Granville" <no.spam@designtools.maps.co.nz> wrote in message
news:457caec8$1@clear.net.nz...
> Nina G. wrote:
> > I am debugging a program in C for Chipcon 2430 processor in IAR Embedded
> > Workbench. When I run the program step by step, I observe that the
execution
> > cursor jumps over some instructions and they never get executed. What
could
> > be the reason for this? A memory mapping issue? Stack corruption?
> >
> > Nina
>
> Do you mean at ASM level, or at HLL/C level ?
The debugger doesn't show any assembler output for the skipped lines.

> Have a careful look a the instructions. Some instructions will execute
> before a debug-trap occurs - ones that access interrupt resource often
> fall into this class.
>
> An easy way to check this type of behaviour, is set a break point after
> the code block, and inspect the accessed SFRs/memory.
> -jg
>

Thank you,

Nina

"larwe" <zwsdotcom@gmail.com> wrote in message
news:1165796097.806372.208120@73g2000cwn.googlegroups.com...
>
> > I am debugging a program in C for Chipcon 2430 processor in IAR Embedded
>
> ... which is an 8051, n'est-ce pas?
Yes.

>
> > Workbench. When I run the program step by step, I observe that the
execution
> > cursor jumps over some instructions and they never get executed. What
could
>
> Are you sure they never get executed? Since you are programming in C,
> single-stepping the program might mean single-stepping through the
> SOURCE line-by-line, which is not the same thing as single-stepping the
> assembly output.
>
The debugger provides a panel with the assembly code. I observe that no
assembly output is generated for the skipped lines.

Thank you,

Nina

Nina G. wrote:
> I am debugging a program in C for Chipcon 2430 processor in IAR Embedded
> Workbench. When I run the program step by step, I observe that the execution
> cursor jumps over some instructions and they never get executed. What could
> be the reason for this? A memory mapping issue? Stack corruption?
> 
> Nina

Do you mean at ASM level, or at HLL/C level ?
Have a careful look a the instructions. Some instructions will execute 
before a debug-trap occurs - ones that access interrupt resource often 
fall into this class.

An easy way to check this type of behaviour, is set a break point after 
the code block, and inspect the accessed SFRs/memory.
-jg

> I am debugging a program in C for Chipcon 2430 processor in IAR Embedded

... which is an 8051, n'est-ce pas?

> Workbench. When I run the program step by step, I observe that the execution
> cursor jumps over some instructions and they never get executed. What could

Are you sure they never get executed? Since you are programming in C,
single-stepping the program might mean single-stepping through the
SOURCE line-by-line, which is not the same thing as single-stepping the
assembly output.

I am debugging a program in C for Chipcon 2430 processor in IAR Embedded
Workbench. When I run the program step by step, I observe that the execution
cursor jumps over some instructions and they never get executed. What could
be the reason for this? A memory mapping issue? Stack corruption?

Nina