Tutorial: Debugging Snickerdoodle from GDB without using Eclipse!

[hedg...@gmail.com]

Hey guys,

Been fighting with this for a while on my quest to be a better baremetal dev. First thing for me was getting a flashing/debugging interface, which we have in the Xilinx SDK, but if you're like me, you detest Eclipse with a passion bordering on murderous. So, I went through for a while and tried to figure out how to get GDB remote debugging over JTAG working with the Cortex-A9. 

This is definitely not going to be a 1-size-fits-all solution, and there will absolutely need to be some modifications, so just be aware YMMV.

Anyway, my hardware:

-Snickerdoodle Black

-AchyBreaky Breakout Board, rev 2.0

-Xilinx Platform Cable USB II

This was all done using tools made available in the vivado free edition on Ubuntu 16.10

Instructions:

1. Navigate to your install directory (default /opt/Xilinx/.... iirc), henceforth called <install_dir>. Run the following command:

$ . <install_dir>/Vivado/2017.1/settings64.sh

This sets up the environment variables and path's needed to run the software used. Yes, the "dot space" is necessary. Informs the bash shell to run the script, save environment variable changes, and then return to allowing user input. 

2. Enter the following in the bash shell: 

$ HW_SERVER_ALLOW_PL_ACCESS=1 hw_server -Llogfile.txt -l0xFC00  &

This spins up the hardware communication server needed by xsdb to communicate over the JTAG interface. 

3. You're going to want to copy the following to a TCL script somewhere as <tcl_script_name>.tcl and modify paths to correctly access your files. Mine is currently referencing a modified example project from the snickerdoodle examples repo, so you may need to run the xilinx eclipse fork once to get this working. 

connect -url tcp:127.0.0.1:3121

source <project_dir>/<project_dir>.sdk/base_block_design_wrapper_hw_platform_0/ps7_init.tcl

targets -set -nocase -filter {name =~"APU*" && jtag_cable_name =~ "Platform Cable USB II 000013bd55ee01"} -index 0

stop

ps7_init

ps7_post_config

targets -set -nocase -filter {name =~ "ARM*#0" && jtag_cable_name =~ "Platform Cable USB II 000013bd55ee01"} -index 0

rst -processor

targets -set -nocase -filter {name =~ "ARM*#0" && jtag_cable_name =~ "Platform Cable USB II 000013bd55ee01"} -index 0

dow <project_dir>/<project_dir>.sdk/hello_test/Debug/hello_test.elf

bpadd -addr &main

4. In your bash shell where you ran hw_server, run:

$ xsdb

Which starts the Xilinx Shell Debugger, and then in that shell run:

xsdb% source <tcl_script_name>.tcl

This resets the board, spins up the debugging layer, adds the initial breakpoint, and flashes your .elf file. Once done, run:

xsdb% xmd
<initialization messages>
XMD% connect arm hw

5. With that, you should have your JTAG chain all initialized and your GDB target server open! Now, all you have to do is open another terminal, run this again: 

$ . <install_dir>/Vivado/2017.1/settings64.sh

and finally, you can run the following to get your GDB shell:

$ arm-xilinx-eabi-gdb hello_test.elf
(gdb) target remote :1234

And you're all set! Let me know if there's anything I can do to make this clearer or clean things up. I know I was really frustrated with getting this set up so I hope it helps someone.

--hedge

[hedg...@gmail.com]

Oh, I'll be trying to get a tutorial up for compiling code for this thing without eclipse later too. Wanted to get this out before it slipped my memory, though. 

[pat...@gmail.com]

Exactly same feeling here about Eclipse (and I think we're far from the only ones).

From this side of the pond, I like very much Crossworks for Arm (UK) and the non-commercial license is reasonably priced for the hobbyist, so from the very beginning with Zynq for me 3 years ago, I moved to Crossworks and never looked back.

So far the drawbacks are:

- based on Xilinx BSP of 3 years ago, I wrote my own but it's now out-of-sync with Xilinx 's current one

- I always flash the bitstream to QSPI prior to switching to Crossworks

- I must use Eclipse if I want to run the Integrated Logic Analyzer

Also my setup works fine for the Microzed/Parallella/MyIR development boards but for the Snickerdoodle, I had to remove the STM32 connections to JTAG/QSPI/SD (there are probably other ways around, but without the Platform Controller source code, I figured that was the easiest way to go).

I'm not using Linux but instead made a partial port of Microsoft dotNet MicroFramework (open-source) so that I wrote the Graphical User Interface in C# under Visual Studio by using a subset of Windows Presentation Foundation. The other Arm core runs FreeRtos and I wrote the Inter-Processor Communication protocol to exchange data between the 2 cores (one is running managed code, the other native code).

I guess the shortcoming is that my setup is incompatible with what others are using thus mostly unshareable. But I usually spend more time on the software side than the FPGA and I clearly prefer toolchains like Crossworks and Visual Studio.