comp.arch.embedded

comp.arch.embedded

[Jos De Laender]

[-- Attachment #1: Type: text/plain, Size: 684 bytes --]

Hi,

Can someone give me some explanation (or the pointer to explanation)
on the following  :


How does one debug code which is running on a target board processor
using a debugger running on a PC or workstation (so running on
a different processor). 
How is synchronized on breakpoints, how is single stepped ...
Does the debugger have knowledge about the target processor
instructions ?
Are there standardizations needed and/or common ? Can each debugger
be used for each processor ? If not, by what it is determined ?

Seems I need really some light in my darkness here. Although I'm
familiar with software and with hardware, I don't see the combination
here.

Thanks in advance.

[-- Attachment #2: .@Signature.Posting --]
[-- Type: text/plain, Size: 721 bytes --]


=== Expressed opinions are not necessarily those of Alcatel ===


     \\\|///      ir. Jos De Laender
     ( 0 0 )      Alcatel - SSD (Switching Systems Division)
   oo0-(_)-0oo    ASIC design - VA21                
  _\   ' `   /_
  \ \ALCATEL/ /   F. Wellesplein 1, B-2018 Antwerp, Belgium
   \ \     / /                                
    \ \   / /     E-mail          : mailto:jdla@sh.bel.alcatel.be
     \ \ / /                                                                 
     o0 Y 0o      Alcatel Bell    : http://www.bel.alcatel.be
       \|/        Alcatel Telecom : http://www.alcatelecom.be
        *         Phone           : (32)(0) 3 240 74 61
                  Fax             : (32)(0) 3 240 99 47

Re: comp.arch.embedded

[Jos De Laender]

[-- Attachment #1: Type: text/plain, Size: 129 bytes --]

Hi,

my previous posting went due to some probably quantum-mechanic
effects into the wrong newsgroup. I'm really sorry for that.

[-- Attachment #2: .@Signature.Posting --]
[-- Type: text/plain, Size: 721 bytes --]


=== Expressed opinions are not necessarily those of Alcatel ===


     \\\|///      ir. Jos De Laender
     ( 0 0 )      Alcatel - SSD (Switching Systems Division)
   oo0-(_)-0oo    ASIC design - VA21                
  _\   ' `   /_
  \ \ALCATEL/ /   F. Wellesplein 1, B-2018 Antwerp, Belgium
   \ \     / /                                
    \ \   / /     E-mail          : mailto:jdla@sh.bel.alcatel.be
     \ \ / /                                                                 
     o0 Y 0o      Alcatel Bell    : http://www.bel.alcatel.be
       \|/        Alcatel Telecom : http://www.alcatelecom.be
        *         Phone           : (32)(0) 3 240 74 61
                  Fax             : (32)(0) 3 240 99 47

Re: comp.arch.embedded

[John M. Mills]

Jos De Laender <jdla@sh.bel.alcatel.be> writes:

>Can someone give me some explanation (or the pointer to explanation)
>on the following  :

>How does one debug code which is running on a target board processor
>using a debugger running on a PC or workstation (so running on
>a different processor). 
>How is synchronized on breakpoints, how is single stepped ...
>Does the debugger have knowledge about the target processor
>instructions ?
>Are there standardizations needed and/or common ? Can each debugger
>be used for each processor ? If not, by what it is determined ?

I can't answer the 'how', but I can describe a working example.  We debugged
embedded Ada83 code cross-compiled from VAX/VMS to MVME147 (68030?) boards.
Motorola provided a monitor-style debugger which could connect by either
serial and ethernet to a remote, which was our VAX.  The code was written
(linked and located) into RAM space on the board for speed reasons, but this
then paid off in debugging, since th monitor-style debugger could place traps,
change parameter data, etc.  No processor 'ICE' was needed (although we did
use an HP 'ICE' system while debugging our in-house VME boards).

The VAX end was DEC's resident debugger, which was able to give us source-level
traces, use the compiled code's symbol table, as if we were debugging native
code.  The compiler was EDS-Scicon's XD-Ada (83): slow and clunky, but we
were happy with the resulting code.  Linking was by DEC's built-in linker,
which has some target-independence like the debugger.

We used the serial port to download a bootstrap for the ethernet support,
then used the enternet to download our code and for debugging communications.
We patched the bootstrap PROM to copy an image of our code into the intended
RAM space in the deployed version.  Since this image matched the debug version
in both location and execution medium, we had little risk in moving from
cross-loaded debug to PROM-booted deployed versions.  The serial step had to
be repeated at each power-up, but we could reset the boards, reload our code,
and start new debug sessions without dropping the Ethernet connections.

We had three processors in our system.  At integration, we debugged them
simultaneously, using a separate console login for each processor (and of
course a separate Ethernet address, through a single physical connection
-- each processor had a dedicated serial link for the lowest-level
bootstraping, but if you could start directly to Ethernet this is not
needed).  An X-Window or virtual-terminal environment would allow this to
be done from a single physical console, but we had different individuals
debugging each processor's executable.  This required a fair amount of trust
and knowledge as to how the various executables were going to interact, but
we were OK for that -- no physical violence occurred!

Perhaps this outline of the process will stimulate further thoughts and
suggestions.  I expect other manufacturers of embedded development packages
have comparable or better approaches.  (These materials were selected about
8-9 years ago and could now be considered obsolete, but they in fact worked.)

Regards -- john mills

-- 
John M. Mills, Senior Research Engineer   --   john.m.mills@gtri.gatech.edu
   Georgia Tech Research Institute, Georgia Tech, Atlanta, GA 30332-0834
        Phone contacts: 404.894.0151 (voice), 404.894.6258 (FAX)
           "Lies, Damned Lies, Statistics, and Simulations."

Re: comp.arch.embedded

[Robert S. White]

In article <34991C2D.127F@sh.bel.alcatel.be>, jdla@sh.bel.alcatel.be says...

>How does one debug code which is running on a target board processor
>using a debugger running on a PC or workstation (so running on
>a different processor). 
>How is synchronized on breakpoints, how is single stepped ...
>Does the debugger have knowledge about the target processor
>instructions ?

  Simple, one installs a "microprocessor emulator" in a PC or a Unix
workstation.  Then you run a debugger (hexidecimal, symbolic, or even
source level) that works with the emulator (which is plugged into the
target hardware, in place of the normal target processor, or it disables
the target processor and runs the rest of the hardware instead).  Often
this requires a "bond-out" chip from the microprocessor vendor.

>Are there standardizations needed and/or common ? Can each debugger
>be used for each processor ? If not, by what it is determined ?

  A lot of variables here.  In general not much is standardized now.
You have to buy unique hardware for each type of target processor.
_____________________________________________________________________
Robert S. White         -- An embedded systems software engineer
e-mail reply to reverse of: ia us lib cedar-rapids crpl shift2 whiter