DEV Community: Zuodian Hu

Using Xilinx SDK to Debug CMake-Defined Executables

Zuodian Hu — Sat, 01 Dec 2018 04:01:28 +0000

The Thing

After arduously pushing through a number of roadblocks, I can now use Xilinx SDK to debug executables defined through a CMake script.

The Background

In the previous posts in this series, I summarized the Alpha Automata project and my journey towards generating Xilinx SDK projects using CMake.

I want CMake's dependency management and automation, and I want to use Xilinx SDK's debugger. Therefore, I must figure out a way to run executables compiled using CMake-generated build systems in Xilinx SDK's debugger. I have spent a lot of my free time in the past three weeks on figuring out how to do just that.

CMake Meets Xilinx System Debugger

Three weeks ago, I had figured out how to generate a Xilinx SDK project using CMake. The last post in this series describes that journey.

CMake Invisible

I could import the SDK project, and compile and link and elf file. However, Xilinx SDK would not give me the option of setting up a debugging profile for the executable.

As you can see, Xilinx SDK refuses to acknowledge the existence of my imported project.

I spent a long time prowling Google without getting a satisfactory answer. In fact, I didn't find many people who were even talking about mashing CMake and Xilinx SDK together. Frustrated with this lack of information, I started experimenting. I created application projects using the Xilinx SDK GUI, and compared the configurations of those projects against the configurations of my imported CMake-generated project. Almost by accident, I found the checkbox I needed to tick:

The imported project must be set to reference the target SoC's Board Support Package project in the imported project's Project Properties. With this one box checked, Xilinx SDK acknowledged my imported project as a candidate for a debugging profile.

I could finally designate the executable compiled using the imported, CMake-generated project for debugging.

At this point, I was ecstatic. As is true for so many things in software, finding the solution took way too long, and the solution turned out to be way too simple.

CMSIS vs Zynq

I happily hit the debug button to run my executable on the target SoC...

...and Xilinx SDK spat in my face just as happily.

I also looked up the address called out in the error to see if it's a legal address for my particular chip to access, and the answer was a resounding "maybe".

According to the Xilinx documentation, address 0x8000_0000 marks the beginning of a programmable logic memory region. In other works, this is one of the address ranges used to read from and write to FPGA logic. Since I hadn't implemented anything in my Zynq SoC's FPGA fabric for this debugging session, my code certainly shouldn't be accessing the FPGA fabric memory range. It just so happens that the CMSIS linker script I was using designates address 0x8000_0000 as the beginning of ROM.

At this point, I groaned to myself. Xilinx SDK automatically generates linker scripts for application projects created using its GUI. And as many times as I hit the Generate linker script button for my CMake-generated project, Xilinx SDK refused to do anything of the sort. In a wild stab into the dark, I designated no linker script and just let GCC choose where it wanted to place all the binary blocks.

And it worked. And I grew a whole new appreciation for GCC and ARM's consistent startup behavior.

All ARM processors immediately fetch the initial stack pointer and initial program counter from a vector table at address 0x00000000 or 0xFFFF0000, depending on the specific processor. This vector table can be moved using the Vector Base Address Register (VBAR).

The State of Alpha

Since last month, not much has changed. I've literally devoted three weeks to get CMake and Xilinx SDK to play nice with each other.

Onwards and Upwards

Now that I have a debugger running on real hardware, I expect to make faster progress implementing the RTOS and to spend less time wrestling with my tools.

I said I would try really hard to post every two weeks, and I did. Things started picking up for me at my real job, and ThanksGiving conspired with my fiance to make me socialize. Hopefully, I'll make one more post before Christmas and my fiance kidnap me.

Using CMake to Generate Eclipse Projects

Zuodian Hu — Sat, 10 Nov 2018 01:43:17 +0000

The Thing

As of an issue-closing commit today, Alpha RTOS has a build process I'm happy to use to develop it with.

Using a CMake project script with an associated toolchain script, I am now able to run compilation of the Alpha kernel in the following environments:

Xilinx SDK on Windows
Ubuntu (in the Windows Subsystem for Linux flavor)

I'm sad that Visual Studio 2017 is not on that list, but for some reason CMake refuses to discover the Microsoft compiler.

The Background

In my first ever post, I summarized Alpha Automata's origins, its status at the time, and where I want to develop it into.

Since this project involves VHDL modules, a lot of my development will occur on a Xilinx Zynq SoC. My current priority is to get the Alpha RTOS kernel running, for several reasons:

I want to deepen my knowledge of real-time operating systems.
I want to design and implement a somewhat complex, highly modular system that I can be proud of. None of the other Alpha Automata components are nearly as complex as an RTOS.
A C++Now 2018 talk gave me, for the first time, a good example of how to use CMake toolchain files. This inspired me to lay the groundwork for using CI/CD in Alpha Automata.
Having a working RTOS makes writing and running test code snippets for every other part of Alpha Automata easier.

The last two bullet points in that list led me to create CMake scripts for Alpha RTOS now, instead of just using projects manually set up in Xilinx SDK and leaving CMake for later.

The CMaking Of

The C++Now 2018 talk showed CMake examples for compiling bare-metal executable images outside of any IDEs. For Alpha RTOS, I want to compile a bare-metal static library in Xilinx SDK. Compiling a static library using Xilinx SDK allows me to skip the tedium of studying the Zynq memory map to create a linker script and trying to figure out how to compile Xilinx libraries that initialize Zynq-specific registers. Using Xilinx SDK forces me to learn how to generate Eclipse projects using CMake.

I welcomed the chance to learn how to generate Eclipse projects using CMake. When I was in Wisconsin Robotics, we created a packet library built using CMake to target Linux and Windows. I wanted the embedded target build system (we used Code Composer Studio at the time) to also use CMake, but we never found the time to make that happen.

The first version of the CMake scripts for Alpha RTOS closely mirror the examples from the C++Now 2018 talk. This was my first attempt at writing a cross-compiling CMake script, and I only wanted to get it to work at all. The first version of these scripts could run compilations targeting the host system, and cross-compile on Linux. However, I couldn't generate an eclipse project using the Eclipse CDT generators provided by CMake. Even if I gave CMake the proper paths to the ARM-target compilers, the CMake Eclipse CDT generators kept making this complaint:

CMake Error: CMake was unable to find a build program corresponding to "Unix
Makefiles".  CMAKE_MAKE_PROGRAM is not set.  You probably need to select a
different build tool.

After some reading and experimentation, I figured out that I needed to point CMake to a proper make executable. After some more digging around, I found out that Xilinx distributes a bunch of GNU tools, including make and gcc, with Xilinx SDK. Armed with this new knowledge, I made improvements to the Alpha RTOS CMake scripts. They toolchain script now makes use of the tools distributed by Xilinx when given a Xilinx SDK version and the Xilinx SDK installation directory.

This generated Eclipse project files that I could import into Xilinx SDK, but for some weird reason, the project wouldn't compile. The compiler kept complaining about not being able to find any of the #include files. I scoured the Internet for answers, but found none. Finally, I took the compile command from the SDK console and tried playing around with it in PowerShell. It took me less than ten minutes to figure out what hours of Google searching couldn't tell me: the GCC version distributed by Xilinx doesn't process -I include paths that have .. in them.

Running gcc with this flag works:

-IC:/SVC/AlphaAutomata/AlphaRTOS/api

Running gcc with this flag fails:

-IC:/SVC/AlphaAutomata/AlphaRTOS/build/../api

My CMake script set parent directories using set and the .. special directory:

set(PARENT_DIR ${CURRENT_DIR}/..)

Using get_filename_component fixed my problem:

get_filename_component(PARENT_DIR ${CURRENT_DIR} DIRECTORY)

With this fix in the [latest version], I can now run compilation using a Xilinx SDK project generated using CMake.

The State of Alpha

Since last month, not much has changed. I've defined the Alpha RTOS API and internal architecture some more, but the kernel is nowhere near a usable state. Now that the CMake scripts are working, I hope to make faster progress.

Onwards and Upwards

I will continue working on Alpha RTOS to get the kernel running and solidify the API.

I made a promise to post on Dev every Wednesday, but the last time I posted was a month ago. I can't stick to a weekly schedule because of work and other life pressures, but I will try really hard to post every two weeks.

My Pet Project

Zuodian Hu — Wed, 03 Oct 2018 06:11:10 +0000

The Thing

Alpha Automata is my cute name for my side project - a highly-modular command and control stack for robotics and automation. As of right now, I envision it to eventually have the following components:

A ROS package acting as a gateway for higher-level applications
A physical-layer-agnostic packet protocol for inter-device communications
An RTOS
A set of SOC peripheral drivers
A set of VHDL AXI peripherals
A set of VHDL I/O modules

The Background

Back in college, I wrote embedded software for Wisconsin Robotics and Badger Robotic Mining Team. I wrote my first tasks and drivers for Wisconsin Robotics' FreeRTOS applications, and wrote a custom RTOS for Badger Robotic Mining Team. Through all that development, I found my love for operating systems, hardware-controlling software, and the pillar of good engineering that is abstraction.

My current job revolves around porting a legacy GUI application to a modern desktop OS while documenting the source code. Having found no creative outlet where I can scratch my itch for embedded systems at work, I have decided to re-architect the RTOS I wrote in college and start building an entire framework around it.

The Goal

I don't see my framework supplanting FreeRTOS or Zephyr. In fact, the Zephyr project does everything I could ever want my own RTOS to do and more, and would be my choice for any serious robotics projects I want to start down the road. I do see the development of my framework, and the writing of my posts here on Dev, honing and expanding my engineering skill set.

A secondary goal of mine is to flush out all the Dev users who are even mildly interested in embedded systems, hardware hacking, IoT, or other such things. As an embedded systems enthusiast, I find it lonely here on a platform seemingly dominated by web developers.

The State of Alpha

I have barely begun this ambitious side project. As of right now, almost none of the components I listed earlier are in a presentable state:

A ROS package acting as a gateway for higher-level applications
- I have never written a single line of code for a ROS package
A physical-layer-agnostic packet protocol for inter-device communications
- I have not made an attempt to start this yet
An RTOS
- I have finished stripping the non-portable code from my college RTOS, and have barely worked out what I think the API should be. I aspire to be even half of what Zephyr is, so I'll probably try to magic the Zephyr API, the CMSIS RTOS API, and the POSIX API together into something mildly usable
A set of SOC peripheral drivers
- No attempt to start this, but I am writing drivers for the VHDL AXI peripherals as I go
A set of VHDL AXI peripherals
- I have tested my PWM module, and it works! I have certainly not tried all the edge cases
A set of VHDL I/O modules
- My UART, PWM, and quadrature modules all work in functional simulation. Who knows if they will all work on hardware?

Onwards and Upwards

I plan on posting my progress here on Dev every Wednesday, and those who are interested can look at my GitHub easily enough.