Wednesday, April 26, 2017
   
Text Size

Remote-Debugging

Remote Debugging Using JTAG Hardware

The Eclipse IDE is very popular to debug remote applications. It uses the cross GDB client installed on the host workstation to connect to the remote GDB server. The remote target must include a GDB server that is reachable either from a serial or Ethernet connection. eCos provides several means to allow remote debugging, however, this article only presents the use of a hardware debugger. The hardware debugger has a GDB server integrated and is used as an interface toward the target. This method is usually more efficient when bringing up a new hardware platform. Using the built-in eCos debugging feature seems more suited for application level debugging and has some limitations.



Some of the well known debuggers are:
- ZY1000 ARM JTAG debugger
- Abatron BDI BDM/JTAG debugger

In usual setup, the workstation is connected to the debugger via Ethernet and the debugger is connected to the remote target via the JTAG interface. Debuggers can usually be configured via telnet and/or a web interface. The BDI debugger for instance also requires a TFTP server accessible on the network to download the initialization script and the CPU registers definition file.

remotedebug

 

RAM Application Debugging

This example requires (2) Eclipse plug-ins to be installed, the C/C++ Development add-on and the embedded plug-in from Zylin. A BDI debugger is used to interface a PowerPC based target. This example demonstrates debugging a RAM application. In order to load the application to the target’s external RAM, some minimal CPU register initialization must be performed. There are two possible methods. With the first method, the CPU registers initialization sequence is part of the BDI configuration script. This script is executed by the BDI probe after issuing a reset of the target. The second alternative is to compile a ROM or ROMRAM application in charge of setting up the CPU IOs. The ROM or ROMRAM application is programmed on the target FLASH or booting device. The later method is used in this example. The target FLASH is programmed with a ROMRAM application (Boot Loader)

 

Once the Eclipse plug-in is installed and the BDI configured and connected to the target, open the Debug perspective in Eclipse and create a new Debug configuration entry under the Zylin Embedded debug type. Use Cygwin or Native depending on your host machine. Give it a name (PPC in this case) and select the application to be debugged.

 

eclipse_step1_570x461

Move to the next tab (Debugger) and select the GDB debugger to be used. In this example, the path to the PowerPC debugger is entered.

eclipse_step2_577x490

The last step is to enter the initialization sequence you wish GDB to execute when starting a debugging session. This is done under the Commands tab.

eclipse_step3_577x490

The initialization steps in this example are:
- target remote 10.10.11.1:2001 : (connect to the hardware debugger on port 2001)
- mon reset : (reset the target CPU)
- mon ti : (execute a single step)
- mon go : (run)
- mon delay 2000 : (let the CPU run for 2 seconds)
- mon halt : (stop the CPU)
- load : (load the application in RAM)
- stepi : (execute a single step in the loaded RAM application)

All commands using the mon suffix are commands specific to the Hardare debugger. In this example, the GDB client is first connected to the server (integrated server into the debugger). The CPU is reset and released in order to execute the ROMRAM application present in FLASH. After 2 seconds, all CPU IOs configuration shall be completed. The CPU is halted and the RAM application is loaded. Debugging can start.

Main GDB Commands

 

Command Action
b main Set breakpoint in the main function
b main.c:123 Set breakpoint in the main.c file at line 123
info b Display breakpoints information
watch $r1==0xa0a0          Set watchpoint on register value (0xa0a0) hit
ena 1 Enable breakpoint # 1
d b 1 Delete breakpoint # 1
dis 1 Disable breakpoint # 1
clear Clear breakpoint at current line
clear function Clear breakpoint at specified function
run Let the CPU start executing instruction
l Show the source code and line number
s Step
si Single assembly step
ti Execute single instruction
c Continue until next breakpoint
where Print backtrace of all stack frames
bt Print backtrace of all stack frames
info locals Print local variables of current stack frame
p n Display content of a variable n
info regi Display CPU registers value
disp /i $pc Will display the current program counter after each step
load Load application to memory
add-symbol-file F A Load symbol file F at the address A
deta Detach debugger
p /x &(_bss_end) Display end address of the un-initialized data segment section
p /x &(_bss_start) Display start address of the un-initialized data segment section
p /x &(_stext)
p /x &(_etext)
Type cast memory (sctruct TYPE *) addr
set debug remote Can be used to monitor the exchange of GDB packets
set logging on Can be used to log all GDB output to a log file for further debugging



 

 

Ultimate Solutions, Inc.
10 Clever Drive
Tewksbury, MA 01876 USA
Phone: 978.455.3383
Fax: 978.926.3091
Email: info@ultsol.com
 
 
 
Quick Link to Support & Resources:
 

      

Twitter Button  

Latest News

Abatron adds support for AppliedMicro's X-Gene™ processor
More Info


USI acquires Zylin ZY1000 product line
Click Here


Available NOW for an introductory price!
Embedded Linux BSP Program from bootbits
Click Here...

Ask about new Boundary Scan capabilities with the ZY1000!
Click for more info