WARP Project Forums - Wireless Open-Access Research Platform

Yes, the SDK has a debugger that you can use to set break points and step through your code line-by-line. This is somewhat complicated by some of the compiler optimizations we were forced to turn on to save on code space, but it still basically works.

You can only debug one of the processors at a time (i.e. either CPU_HIGH or CPU_LOW but not both). Whichever processor you are not debugging will be free running in the background waiting on IPC messages from the processor you are debugging. Here are the steps to get the SDK debugger to work:

1. Click and highlight the project in the "Project Explorer" window that you want to debug. For example, let's say you want to debug the DCF. For this, you'd click and highlight the "wlan_mac_low_dcf" project.

2. You should see a little bug icon at the top of the screen in the main tool bar. If you mouse over this icon it will say "Debug As...". Click the small arrow next to this icon and select "Debug Configurations".

3. In the left pane of this new window, click and highlight "Xilinx C/C++ ELF."

4. In the toolbar of this window, there is an icon that looks like a sheet of paper with a "+" icon the top corner. If you mouse over this icon it will say "New launch configuration". Click this icon.

5. A new launch configuration will appear in the left pane under "Xilinx C/C++ ELF" whose name will match the project you highlighted in the first step. For the DCF, the name will be "wlan_mac_low_dcf Debug." In the right pane, there are a few tabs we need to go through.

  5a. Click the "Debugger Options" tab and uncheck the "Stop at main() when debugging." This isn't critical, but I find it annoying that once you hit the "Play" button during a debugging session the debugger automatically places a breakpoint at the first line of your main() function.

  5b. Click the "Common" tab. Check the box next to "Debug" to display this run configuration in the favorites menu. Also uncheck the "allocate console." There is a notion of UART-over-JTAG, but I haven't used it. Finally hit "Apply" and the "Close."

6. Program your board like normal using "Xilinx Tools" -> "Program FPGA." In the dialog box that pops up, you should an ELF file listed in each of the two processors. Click on the arrow next to the ELF for the processor that you want to debug. In the case of the DCF, you would click the arrow next to the "wlan_mac_low_dcf.elf" file. Change this to "bootloop." The reason for this is that we will actually download the ELF and attach the debugger in the next step. By placing the bootloop ELF in the processor you want to debug, you'll prevent any execution after the board is programmed and before you can start the debugging session.

7. Finally, click the arrow next the the "bug" icon again. This time, click the name of the configuration we created earlier. In the case of the DCF, the name will be "wlan_mac_low_dcf Debug." This will attach the debugger and download the DCF ELF. This will take a few seconds. A pop up window will appear that will ask if you want to switch the SDK into the Debug perspective. Say yes. The Debug perspective is pretty intuitive and makes it easy to add breakpoints, read and write specific memory addresses, etc.

8. Once you are ready, hit the "play" arrow at the top of the screen and code will start to execute. The code execution will automatically pause if it runs into a breakpoint you set up. Or you can manually press the "pause" button to see where the code is.

I think you forgot to post your picture.

Those are assembly instructions. This document goes into details on the instruction set used by the MicroBlaze. Do you really need to be that low-level? I find the debugger to be most useful when staying at the high-level C code with setting break points, reading specific memory addresses, etc.