* comp.arch.embedded @ 1997-12-18 0:00 Jos De Laender 1997-12-18 0:00 ` comp.arch.embedded John M. Mills ` (2 more replies) 0 siblings, 3 replies; 4+ messages in thread From: Jos De Laender @ 1997-12-18 0:00 UTC (permalink / raw) [-- 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: comp.arch.embedded 1997-12-18 0:00 comp.arch.embedded Jos De Laender @ 1997-12-18 0:00 ` John M. Mills 1997-12-18 0:00 ` comp.arch.embedded Jos De Laender 1997-12-19 0:00 ` comp.arch.embedded Robert S. White 2 siblings, 0 replies; 4+ messages in thread From: John M. Mills @ 1997-12-18 0:00 UTC (permalink / raw) 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." ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: comp.arch.embedded 1997-12-18 0:00 comp.arch.embedded Jos De Laender 1997-12-18 0:00 ` comp.arch.embedded John M. Mills @ 1997-12-18 0:00 ` Jos De Laender 1997-12-19 0:00 ` comp.arch.embedded Robert S. White 2 siblings, 0 replies; 4+ messages in thread From: Jos De Laender @ 1997-12-18 0:00 UTC (permalink / raw) [-- 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: comp.arch.embedded 1997-12-18 0:00 comp.arch.embedded Jos De Laender 1997-12-18 0:00 ` comp.arch.embedded John M. Mills 1997-12-18 0:00 ` comp.arch.embedded Jos De Laender @ 1997-12-19 0:00 ` Robert S. White 2 siblings, 0 replies; 4+ messages in thread From: Robert S. White @ 1997-12-19 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~1997-12-19 0:00 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1997-12-18 0:00 comp.arch.embedded Jos De Laender 1997-12-18 0:00 ` comp.arch.embedded John M. Mills 1997-12-18 0:00 ` comp.arch.embedded Jos De Laender 1997-12-19 0:00 ` comp.arch.embedded Robert S. White
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox