- 1 JTAG Debugging with Dangerous Prototypes BusBlaster v4.1a
- 2 Setup
- 3 Debugging
- 4 Stay Tuned for more
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 . 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.
- one Wandboard Unit (does not matter which CPU-Version single/dual/quad)
- one BusBlaster v4 Unit (Avalable at )
- 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
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:
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 uses scriptes for detecting and debugging. I will provide those scripts down below ... enjoy!
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.
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
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 ...