JTAG-BusBlaster

From Wandboard Wiki
Jump to: navigation, search

JTAG Debugging with Dangerous Prototypes BusBlaster v4.1a

The BusBlaster is a FTDI-based JTag-Debugger so this documentation might be used for other Debuggers (like Olimex etc.). For I only own a BB I assume you do too. You can get it at [1]. The advantages using JTAG are you have nearly 100% control over your target. You can stop it anytime access memory you are usually not allowed to, due to restrictions by the OS. So it can be used for Application and System development likewise. It helps you exploring your Wandboard as well. For instance: you can stop the boot loader and step through its code allowing you to see how keyboard inputs are dispatched by the command prompt via the UART, as well as examining the receive buffer in memory. It also enables "bare metal" development because you can deploy code directly into the memory and executed it. This Page describes how to set up a powerful and low cost method for debugging and advanced application and system development.

Requirements

  • one Wandboard Unit (does not matter which CPU-Version single/dual/quad)
  • one BusBlaster v4 Unit (Avalable at [2])
  • UART Port/UART -> USB Adapter (you should have this anyhow)
  • PC with free USB Port (2.0 at least or else you will die waiting for your debugging)
  • Operating System: Linux/Windows/Mac
  • OpenOCD Version 0.7.0 build for your OS
  • Wandboard JTAG adapter (build it your self by provided schematics below)
  • A DSO (might come in handy for diagnosis)
  • Linaro ARM GCC and BinUtils

Setup

The Wandboard JTAG Connector

The Wandboard JTAG Connector is not populated by default so you have to get an 8 Pin Connector, best with a 90° angle - because of WBs Quads Heatsink, if you have a Dual or Single you can use straight ones as well - with a pin distance of 2mm and solder it onto the board (where it reads "JTAG" and is on the opposite of the EDM-Connector). You will need the fitting counterparts to connect to the pin array.

I thought this was the cleanest solution so see it as an recommendation. You may as well solder a cable onto the Wandboard instead of using the angled connector.

Once soldered your cable/connector onto the Wandboard, you can proceed with the JTag Adapter.

The JTAG Adapter/Debugger

Wire your hardware together as shown in this file:

File:Wbjtag.pdf

You may use a bundle of wires for this. I build a small adapter with a prototype point raster board and soldered the wires accordingly. My schematic also shows the GND and VCC lanes as not connected. You can not connect with OpenOCD correctly by getting the power just from the JTag-Debugger. So you may or may not add these lines. It does not matter since you have to power the Wandboard with a separate supply.

Make sure your JTag-Adapter is connected to the 20-Pin Arm-JTAG connector of the BB. Disable target powering by unbridging the Jumper next to the Connector. The Buffer Logic "Mode" Jumper should be set to "Normal".

With these Setting you should be able to start debugging. Once everything is put together correctly you can power up the Wandboard and proceed with the next section.

OpenOCD

OpenOCD uses scriptes for detecting and debugging. I will provide those scripts down below ... enjoy!

Detecting Taps

source /usr/share/openocd/scripts/interface/busblaster.cfg
adapter_khz 1000

As you may see I using a Linux environment. If you are running Windows you should adapt the source path to match your file system. I stored this in a file called wandboard.cfg. You can execute the scripts by:

openocd -f wandboard.cfg

The output should look like this:

Open On-Chip Debugger 0.7.0 (2013-05-15-17:28)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
adapter speed: 1000 kHz
Info : max TCK change to: 30000 kHz
Info : clock speed 1000 kHz
Warn : There are no enabled taps.  AUTO PROBING MIGHT NOT WORK!!
Warn : AUTO auto0.tap - use "jtag newtap auto0 tap -expected-id 0x4ba00477 ..."
Warn : AUTO auto1.tap - use "jtag newtap auto1 tap -expected-id 0x00000000 ..."
Warn : AUTO auto2.tap - use "jtag newtap auto2 tap -expected-id 0x2191c01d ..."
Warn : AUTO auto0.tap - use "... -irlen 8"
Warn : AUTO auto1.tap - use "... -irlen 5"
Warn : AUTO auto2.tap - use "... -irlen 2"
Error: auto2.tap: IR capture error; saw 0x0003 not 0x0001
Warn : Bypassing JTAG setup events due to errors
Warn : gdb services need one or more targets defined

If you are seeing these Lines your setup is complete and you may proceed with the next section.

Using the i.mx6 as a Target

As of version 0.7.0 OpenOCD claims to support the i.mx6 application processor.

source /usr/share/openocd/scripts/interface/busblaster.cfg
source /usr/share/openocd/scripts/target/imx6.cfg
adapter_khz 25000

As of version 0.8.0 OpenOCD support the i.mx6 application processor should use the ftdi driver (the older driver is now deprecated).

Create a configuration file (wandboard.cfg) and place the following: (you may need to drop the "local" depending on how you installed openocd, I used the git source defaults using the following flags --enable-maintainer-mode --enable-ftdi --enable-usb_blaster_libftdi)

source /usr/local/share/openocd/scripts/interface/ftdi/dp_busblaster.cfg
source /usr/local/share/openocd/scripts/target/imx6.cfg
adapter_khz 25000

Then start OpenOCD using

openocd -f wandboard.cfg

depending on permissions you may need to "sudo"


The output might be this:

Open On-Chip Debugger 0.7.0 (2013-05-15-17:28)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
Warn : imx6.sdma: nonstandard IR value
RCLK - adaptive
adapter speed: 1000 kHz
Info : max TCK change to: 30000 kHz
Info : clock speed 1000 kHz
Polling target imx6.cpu.0 failed, GDB will be halted. Polling again in 100ms
Polling target imx6.cpu.0 failed, GDB will be halted. Polling again in 300ms
Info : JTAG tap: imx6.dap tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : TAP imx6.sdma does not have IDCODE
Info : JTAG tap: imx6.sjc tap/device found: 0x2191c01d (mfg: 0x00e, part: 0x191c, ver: 0x2)
Info : imx6.cpu.0: hardware has 6 breakpoints, 4 watchpoints
Polling target imx6.cpu.0 succeeded again

According to the OpenOCD Manual no error message popping up means everything went fine.

I tuned the adapter_khz a bit to 27272 which is the highest value possible (above that got me a lot of errors). I recommend to go slowly for diagnoses. The shipped scripts seem to work quite well.

Debugging

Connecting with GNU GDB

To connect to your JTAG-Target using OpenOCD you simply start OpenOCD as shown above using your config file. OpenOCD automatically starts a remote GDB socket which you need to connect your GDB to. It is important to use the ARM Toolchain for it, as far as I understood, dissembles the prgrams in Memory with the correct ARM Instruction Mnemonics. So for this you need to download the latest Linaro ARM Tool suite and BinUtils.

After download an installation start arm-linux-gnueabihf-gdb and type:

target remote localhost:3333

which outputs:

0x1000406a in ?? ()
(gdb)

Which if everything works well should connect you to your Target Hardware. There a few commands I "found out" yet so first of all:

(gdb) help mon

will give you a nice list of a possible commands available for your target. To execute a Command you have to write mon in front of some of your commands.

Some "state checkers" also work so for instance:

(gdb) mon arm core_state
core state: ARM
(gdb)

However more specific commands seem not to work for instance:

(gdb) mon imx6.cpu.0 arm disassemble 0x00000000 0x0f
Address translation failure
in procedure 'imx6.cpu.0'

I don't know if it is my set up or a faulty configuration/hardware/both. But I assume it has something to do with the Info : TAP imx6.sdma does not have IDCODE line in the OpenOCD output. All components where found except the DMA unit, which might be the reason why an "address translation fault" occurs.

I reject what I said and claim the opposite =) : The mistake was to use a normal "Intel" GDB. Do not do that or you get nonsense as readout as well as wrong mnemonics. As far as can tell OpenOCD works pretty well. I could stop the processor and disassemble the instructions with the disassemble command. You'd do good to ignore the help messages by help mon. You will not need them - at least I did not for my first steps -, may be if you have to lift heavier tasks. You can use default gdb commands (remember to use the ARM GDB!) to explore your Wandboard's memory. If you use the disassemble command you still get those memory translation errors sometimes, but you get the correct results as well. With that you should have everything you need to start developing debugging and exploring.

The OpenOCD configuration

As promised my OpenOCD configuration, though its quite manageable:

#use the busblaster configuration shipped with OpenOCD:
source /usr/share/openocd/scripts/interface/busblaster.cfg

#include the imx6 configuration
source /usr/share/openocd/scripts/target/imx6.cfg

#for production
adapter_khz 27272 

#use this for diagnosis (e.g. connection testing with DSO)
#adapter_khz 1

As for now there is no support for multiple cores. If you take a closer look into the imx6.cfg shipped with OpenOCD 0.7.0 you'll find the base addresses for other cores (if any). You can use the example to define more debug targets and use those as well with GDB.

Stay Tuned for more

I did not get any further so stay tuned for more once there are new things to share. If you are ahead of my state please feel free to edit this page. So long ...