How ICE works

I hav every basic doubts about ICE working. I read that ICE internal
processor replace the target CPU and provide various debugging
features.
My doubt is who execute the code? whether only ICE processor or ICE
and target CPU both!
If only ICE then how its execution is different from target CPU? how
it could provide so many debugging facilities including real time
tracing? Is target CPU support is required here?
If ICE and target CPU both then how both execution synchronized
without effecting the execution speed? Hoe emulator high-speed RAM
mapping over target CPU address space get synchronized?

Thanks in advance

Regards,
Sachin

>I read that ICE internal
>processor replace the target CPU and provide various debugging
>features.
>My doubt is who execute the code?

Think about what you just said. The ICE CPU "replaces" the target CPU. This
means you unplug the target CPU and plug in the ICE connector.

An ICE usually contains a special version of the CPU with more debugging
abilities built-in.

Gary Kato wrote:

> >I read that ICE internal
> >processor replace the target CPU and provide various debugging
> >features.
> >My doubt is who execute the code?
>
> Think about what you just said. The ICE CPU "replaces" the target CPU. This
> means you unplug the target CPU and plug in the ICE connector.
>
> An ICE usually contains a special version of the CPU with more debugging
> abilities built-in.

in some cases you don't unplug the target CPU; the ICE sends signals to it
which make it go idle.  Sometimes the ICE has its own RAM on it to replace your
flash chips... so you download the program to the ICE ram and run it from
there.  The ICE cpu isn't necessarily a highly specialized CPU that performs
extra debug functions as the hardware on the ICE can be designed to augment its
CPU.

David

Sachin wrote:
> I hav every basic doubts about ICE working. I read that ICE internal
> processor replace the target CPU and provide various debugging
> features.
> My doubt is who execute the code? whether only ICE processor or ICE
> and target CPU both!
> If only ICE then how its execution is different from target CPU? how
> it could provide so many debugging facilities including real time
> tracing? Is target CPU support is required here?
> If ICE and target CPU both then how both execution synchronized
> without effecting the execution speed? Hoe emulator high-speed RAM
> mapping over target CPU address space get synchronized?
> 
> Thanks in advance
> 
> Regards,
> Sachin

Hi Sachin,

You didn't say what kind of microcontroller you are looking at.

For traditional small microcontrollers, e.g. 8051, the processor
on the target board is put into a special mode that all the pins
should be tristated.  The program execution is handled by a special
version of the same chip in ithe ICE, connected in parallel to the CPU 
on target board, but with separated programmable memory interface 
connected to RAM so that you can download you program and execute it. 
(Standard 8051 have program memory interface mux with I/O pins).
So the CPU on the target board don't have to do anything, just idle.

For newer processors, e.g. ARM7 based chips, the ICE connected to the 
JTAG interface of the CPU.  The execution of the program is still 
carried out by the CPU on target board, but the CPU can be stop by 
internal break point unit.  Once a break point is hit, the CPU stop 
program execution and the ICE (e.g. Multi-ICE) will then able to access 
register values and memory contents through the JTAG interface.  So in 
general the ICE only monitor the status of the CPU through JTAG and 
access to the registers/memory when the execution of program stopped.

Multi-ICE in ARM do not provide real time trace.  You need a separate 
tools call Multi-Trace (I think it is now replaced by a newer version 
called Real-View Trace).  That requires a trace interface on the chip 
and a logic block called ETM (Not all ARM chips got ETM!  That's depends 
if chip manufacturer put it onto their chip).  The ETM output data like
- a instruction is/is not execution
   (ARM instruction executions can be based on conditions)
- a branch is/not taken place
- new program counter after branch (this is required when new PC is 
generate from register)

Since the debugger should have a copy of the same program image, it can 
then reconstructe the whole program execution by the above information.
Since the information require is not huge, the trace port can be as 
narrow as 4-bit wide.

For simple program debug, you don't necessary need real-time trace. 
Multi-ICE support single step, break points and watch points so it 
covered basic debug needs.

Different ARM core have different JTAG scan chain setup, some have 
different JTAG IDs and some have different length in their JTAG 
instruction registers. So before buying your tools you need to make sure 
the tools support the ARM chip you used.

Sorry that all information I can provided are 8051 and ARM base.
Hope these information helps.
regards,
Joe

Thanks Everyone.

From this discussion what I understand is program execution is take
place at the target CPU but ICE processor can control and monitor the
target CPU execution. It can put breakpoint, can execute program in
single step etc.
And target CPU supports these debug facilitate through its JTAG
interface
through which ICE access the target CPU.

Is this understanding correct?

Here again my doubt is, what protocol or mechanism ICE use to access
the target resources? Is there any agent (some program) reside at the
target also (apart from JTAG interface) to provide the target resource
access to the ICE?

Regards,
Sachin

Joe <joe_y@invalid_address.nospam.com> wrote in message news:<clh1lg$9ti$1$8300dec7@news.demon.co.uk>...
> Sachin wrote:
> > I hav every basic doubts about ICE working. I read that ICE internal
> > processor replace the target CPU and provide various debugging
> > features.
> > My doubt is who execute the code? whether only ICE processor or ICE
> > and target CPU both!
> > If only ICE then how its execution is different from target CPU? how
> > it could provide so many debugging facilities including real time
> > tracing? Is target CPU support is required here?
> > If ICE and target CPU both then how both execution synchronized
> > without effecting the execution speed? Hoe emulator high-speed RAM
> > mapping over target CPU address space get synchronized?
> > 
> > Thanks in advance
> > 
> > Regards,
> > Sachin
> 
> Hi Sachin,
> 
> You didn't say what kind of microcontroller you are looking at.
> 
> For traditional small microcontrollers, e.g. 8051, the processor
> on the target board is put into a special mode that all the pins
> should be tristated.  The program execution is handled by a special
> version of the same chip in ithe ICE, connected in parallel to the CPU 
> on target board, but with separated programmable memory interface 
> connected to RAM so that you can download you program and execute it. 
> (Standard 8051 have program memory interface mux with I/O pins).
> So the CPU on the target board don't have to do anything, just idle.
> 
> For newer processors, e.g. ARM7 based chips, the ICE connected to the 
> JTAG interface of the CPU.  The execution of the program is still 
> carried out by the CPU on target board, but the CPU can be stop by 
> internal break point unit.  Once a break point is hit, the CPU stop 
> program execution and the ICE (e.g. Multi-ICE) will then able to access 
> register values and memory contents through the JTAG interface.  So in 
> general the ICE only monitor the status of the CPU through JTAG and 
> access to the registers/memory when the execution of program stopped.
> 
> Multi-ICE in ARM do not provide real time trace.  You need a separate 
> tools call Multi-Trace (I think it is now replaced by a newer version 
> called Real-View Trace).  That requires a trace interface on the chip 
> and a logic block called ETM (Not all ARM chips got ETM!  That's depends 
> if chip manufacturer put it onto their chip).  The ETM output data like
> - a instruction is/is not execution
>    (ARM instruction executions can be based on conditions)
> - a branch is/not taken place
> - new program counter after branch (this is required when new PC is 
> generate from register)
> 
> Since the debugger should have a copy of the same program image, it can 
> then reconstructe the whole program execution by the above information.
> Since the information require is not huge, the trace port can be as 
> narrow as 4-bit wide.
> 
> For simple program debug, you don't necessary need real-time trace. 
> Multi-ICE support single step, break points and watch points so it 
> covered basic debug needs.
> 
> Different ARM core have different JTAG scan chain setup, some have 
> different JTAG IDs and some have different length in their JTAG 
> instruction registers. So before buying your tools you need to make sure 
> the tools support the ARM chip you used.
> 
> Sorry that all information I can provided are 8051 and ARM base.
> Hope these information helps.
> regards,
> Joe

Sachin wrote:
> Thanks Everyone.
> 
> From this discussion what I understand is program execution is take
> place at the target CPU but ICE processor can control and monitor the
> target CPU execution. It can put breakpoint, can execute program in
> single step etc.
> And target CPU supports these debug facilitate through its JTAG
> interface
> through which ICE access the target CPU.
> 
> Is this understanding correct?
> 
> Here again my doubt is, what protocol or mechanism ICE use to access
> the target resources? Is there any agent (some program) reside at the
> target also (apart from JTAG interface) to provide the target resource
> access to the ICE?
> 
> Regards,
> Sachin
> 

Again, this depends on what chip you are using.
There are many many different debug methodlogies.

Most ICE for 8-bit processors replace the processor on target board.
(Processor on target board place in Idle mode or removed completely).
In this case, the chip inside the ICE is specailly desige to support the 
debug functions.

Most ICE for 32-bit processors connect to tbe build-in debug circuit in 
the procesor on the target board and control the debug circuit inside 
the chip. In this case, no debug program is required inside the chip.

Some ARM chips have build in flash ROM that contain debug software so 
that it can talk to a debugger through RS232, some don't have this 
feature.  In this case, the CPU on the target board execute the user 
application as well as some debug functions. The debug software on chip, 
in this case, is an ARM product called Angel. Other chips might have 
different firmware to do the same function.

Many people use JTAG to control the debug circuit in ARM chips. Some use 
  special hardware like Multi-ICE, some use printer port on PC to drive 
the JTAG interface directly (slow, but cheap).

A number of other processor have their own special debug interface. To 
understand how it work, you need to find the data sheet of the product.

Joe

tosb13@yahoo.com (Sachin) wrote in
news:d7c1493f.0410250057.2db46082@posting.google.com: 

> Thanks Everyone.
> 
> From this discussion what I understand is program execution is take
> place at the target CPU but ICE processor can control and monitor the
> target CPU execution. It can put breakpoint, can execute program in
> single step etc.
> And target CPU supports these debug facilitate through its JTAG
> interface
> through which ICE access the target CPU.
>
> Is this understanding correct?

Yes, for CPUs that support JTAG debugging.
 
> Here again my doubt is, what protocol or mechanism ICE use to access
> the target resources? 

The JTAG spec. defines the physical layer protocol but the scan chain used
to access the CPU registers is vendor-specific. 

> Is there any agent (some program) reside at the
> target also (apart from JTAG interface) to provide the target resource
> access to the ICE?

The JTAG debug hardware on the chip, not usually software. A simple
example is a hardware breakpoint register that can be set via the JTAG
interface. Then, when the CPU started, compare logic in the CPU will fire
and cause a debug exception when the address matches the hardware
breakpoint register address.