Using this kind of JTAG-GDB Server is very risky. In fact is it very likely that the JTAG-GDB server will damage parts of your hardware and/or your software.
For example:
Since you're knowing that a lot can go wrong you should isolate a probe as match as possible. You better treat the embedded ARM target, the JTAG-GDB Server and gdb itself as one bigger probe that have to run at a standalone development platform.
This is not a game, and it will never give fun to you.
This should be a tool, one day. But it isn't yet.
When it is working some day, it might look like this.
The "JTAG-GDB server" is a program for integrating the ARM-Embedded ICE logic with the GNU-Debugger GDB. This program is running at a host system (for example an i386 PC) and it is directly (or an extra Level Shifter/Line Driver) connected with the ARM Embedded ICE logic of the target platform using the JTAG interface. At the other side, the server has to understand GDB's own remote debug protocol which is transported over ether a RS232 or a TCP/IP link (including the loopback interface so that the debugger and the server can live at the same machine).
The host system can be any embedded CPU platform that has an direct port to emulate the standard JTAG signals. For example the host platform can be standard PC with a parallel IO using a Level Shifter/Line Driver. These drivers can also be standard device like Altera Byteblaster, Xilinx DLC, Lattice ISPDLC, Macraigor Wiggler etc or your own tinker solution.
The target machine can be any ARM CPU with JTAG and embedded ICE logic.
The first stage of the server will start with limited features:
# establish physical connection
+--------+ +-------+ +-----------+ +-----+ | ARM | JTAG-Cable | phys. | LPT-Port| | TCP/IP | | | target +------------+ Cable +---------+ gdbserver +--------+ GDB | | board | | Driver| | | | | +--------+ +-------+ +-----------+ +-----+
# The ARM traget will be controlled by gdb # First you need to be connected via TCP/IP e.g.
target remote :1234
# Before anything can be done you have to setup the gdbserver. # All setup and all changes of internal states of the gdbserver are be done via # GDB's rcmd. # To send a rcmd you must type the keyword "monitor" at GDB's command line # interface. # # Setup # Set up memory map layout of ARM target board. # It is possible to deal with different versions of memory maps. # For example if we want two version of the same memory map.
monitor MemMap.MaxNum = 2 monitor MemMap.MaxEntrys[0] = 3 monitor MemMap.MaxEntrys[1] = 3 monitor MemMap[0][0] = rom, 8, 0x00000000, 8 KByte monitor MemMap[0][1] = rom, 16, 0x00010000, 8 KByte monitor MemMap[0][2] = io, 32, 0xFFFE0000, 16 KByte monitor MemMap[1][0] = flash, 8, 0x00000000, 8 KByte monitor MemMap[1][1] = ram, 16, 0x00010000, 8 KByte monitor MemMap[1][2] = sfa, 32, 0xFFFE0000, 16 KByte
# Each entry in the map containing: # type of memory, bus size, base address and its length. # supported memory types are: # RA (ram) --- read and writeable memory # RO (rom) --- read only memory (read once) # RE (rereadRom) --- read only memory (read again after every program break/stepping stop) # F (flash) --- programmable memory (with special command sequences) # C (cache) --- (reserved e.g. to invalidate it on go) # A (applflash) --- (reserved e.g. for application flash) # U (unreal) --- pseudo RAM, that only exist at server side but not at real target side # I (io) --- to make clear that the debugger never access it directly # S (sfa) --- special function area (e.g. to configure special on chip register) # W (workspace) --- optional area for GDB (e.g. to program a flash) # D (delete) --- delete entry by marking it as being undefined # # supported bus sizes are 8, 16, 32 or a special case # Special cases are embedded flash controllers here a value bigger # than 32 describes the kind of controller # 128 -> Philips @ LPC21xx # 132 -> Atmel @ At91SAM7 # 164 -> STM @ STR71x, STR91x or STM32x # # To activate the desired memory map we send (assuming it is the second one):
monitor UseMemMap[1]
# Define a sequence of commands (e.g. to setup a SDRAM device). # A sequence entry containing the bus size, address and its value.
monitor CmdSequence.MaxNum = 1 monitor CmdSequence.MaxEntrys[0] = 3 monitor CmdSequence[0][0] = 32, 0xFFFE0008, 0x0 monitor CmdSequence[0][1] = 8, 0xFFFE0010, 0xf0 monitor CmdSequence[0][2] = 8, 0xFFFE0011, 0x0f
# To start this sequence send:
monitor Cmd[0]
# The command sequences are more powerfull than it may looks like. # Each sequence element has its own shadow register. # So you can write and read from target CPU and collect its data at a later state. # Additional a few machine code instructions are available. # So you can calculate new (shadow register) data, branch to a sequence # position etc. (for more info see remote GDB commands below)
# To load program data (e.g. at file named "HEXFILE") into gdb # and the memory maps of the gdbserver use:
load HEX_FILE
# This is only necessary if you are going to write the program data itself into RAM or Flash. # If you are having an already programmed target device, you don't need GDB's "load" command. # The gdbserver will collect the data from the target if GDB is requesting for it. # If your program data should transferred into RAM you have to use GDB's "load" command to load # the data into the cache of the gdbserver. # The gdbserver will write this data into RAM on the next "step","continue" or "next" command. # If your program data is going to resides in Flash you have to use GDB's "load" command, too. # To decide which data have to be programmed, which have to be erased and programmed, and which # are already present, you have to do a check first.
# To check if we must program a Flash at address 0x0 or not use:
monitor VerifyFlash 0x0
# (Here info output appears only at server side, no info output at GDB side)
# Since the transaction may take a while we can do the same. # Setting the server into "FakeContinue" mode. # After receiving a GDB-Continue command the server is able to # transfer data to GDB-STDOUT. # In "FakeContinue" mode the GDB-continue is not delivered to the target side. # (Now we got some output at GDB side too.)
monitor FakeContinue = 1 monitor VerifyFlash 0x0 continue monitor FakeContinue = 0
# To collect the result of this check # <the check of the data from "load HEXFILE" (stored at server side) and the # data inside of the FLASH> use:
monitor FlashState
# If we decide to program the first sector of the Flash we send.
monitor ProgramFlash 0x0 1
# Here the first parameter "0x0" is the sector address and # the second parameter "1" give the number of sectors to be programmed. # To be be sure that programming succeeds we may verify the flash again.
# As you have defined inside of your linker script, # you have two kinds of addresses spaces inside of an Elf-file: # The VMA (the virtual memory address) and the LMA (load memory address). # The LMA is the layout after Reset but before CRT startup code has taking place. # The VMA is the layout after CRT startup code has finished. # All symbol table relevant debugging is done inside of the VMA space.
# To do a real high level debugging GDB needs the debug symbols.
symbol-file ELF_FILE
# As a side effect the server variable forceTempHWBreakAtMain is set to '1'. # So no other breakpoints will be handled until function main is reached. # If you like to debug the CRT startup code itself you might set # monitor forceTempHWBreakAtMain = 0 # to cancel this behaviour.
# Depending which kind of platform and ARM core is used additional commands # have to be send to the target.
# At least you need to reset the target PC register monitor Register[15] = 0x0
# Also you need to switch into ARM - supervisor mode with all Interrupts disabled. # So reset the target CPSR register, too. monitor Register[16] = 0xD3
# Until now, no real debugging action has been taking place. # This was only the first setup stuff. # But now you can start debugging the ARM target. By stepping with
si
# or running with "continue" (not the "run" this is reserved for native debugging)
c
# Since the Setup of the target machine is a little bit lengthy. # You might like to put those instructions into a GDB script file. # Take a look at the example directory for more info. # See .gdbint and *.gdbscript files.