Has anyone managed to connect a MicroBlaze instantiated in a Xilinx FPGA to anything other than the Xilinx tools (SDK or Vitis) for download and debugging?
I'm targeting a VCU29 and have licenses from Xilinx for Vivado etc; I have already extracted the libraries, source and GCC tools and constructed a makefile that will build my applications.
I'm resigned to using Vitis to load the initial bitfile but would really like to download the code and operate the JTAG from a tool that better matches SW development flow - Eclipse with OpenOCD? Perhaps over the built-in USB->Serial->JTAG interface? I believe I'd be content with just the interface offered through GDB.
I'd really like to know if anyone has tried this with either success or failure or maybe has one of those "Why don't you just..." lateral thinking ways of solving the problem.
Yes, my team does not use Vitis or SDK to build, deploy, or connect to MicroBlazes.
If you generate your BSP and a linker script with Vitis, you can then build using mb-gcc and link with mb-ld directly. To get these into your PATH, just source the settings script that Xilinx provides with their tools in <Vitis_root>/settings64.sh.
As for loading and debugging - if you source the same script, then you will have access to xsdb. Once you have XVC running (i.e. connecting to your board with Vivado HW manager), then you can launch xsdb and inside run connect or connect -xvc-url <host>::<port> if you are running on a different host. While connected, you can run targets to identify your MicroBlaze, and then select the MicroBlaze with target 5.
While you have the MicroBlaze selected, you can load <path to elf> and run a number of debugging commands. Just run help while connected to see your options.
Related
I want to setup the following environment: I've got a STM32H753I-EVAL2 eval board, connected on a Windows PC. Until now I was developping and debugging locally on this PC with STM32CubeIDE. For several reasons my code source is on a Linux server (Samba mounting) so it takes forever to build a project. Hence I want to develop on the linux server from my Windows machine.
Compiling is working fine (and is way faster) but the issue is about debugging. I know it is possible to debug remotely, the Debug Configuration window from Eclipse (I'm using OpenOcd) allows to connect to a remote GDB server. What I don't know is how to start a GDB server on the Windows machine that will connect to the STM32 board ?
Sorry for the "answer to myself" but I think it might be useful for others (and even to me when I have forgotten in a few weeks ;) ).
Here is how to do.
on host side (on the machine where the eval board is physically plugged in) you have to manually launch the GDB server application that comes with STM32CubeIDE installation. See STMicro application note UM2576 for details. The default command line is:
ST-LINK_gdbserver.exe -d -v -cp "C:\ST\STM32CubeIDE_1.0.0.19w12patch\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.externaltools.cubeprogrammer.win32_1.0.0.201903011553\tools\bin"
Now you've done the hardest. On server/remote side you have to setup the Debug Configuration to use OpenOcd with option "Connect to remote GDB server" and simply enter IP address and port number (which is not 3333 by default but 61234, but it can be modified).
This setup is working fine, even if I encoutered some instabilities during debugging once in a while.
I see two (maybe three) options
Use an alternate GDB server (see below)
Run the GDB server from STMCubeIDE in isolation (see OP's answer for Windows, this answer for Linux)
GDB Serial (not really an option right now but I'll share my experience so far)
I have used the second option to succesfully debug my target using arbitary GDBs such as gdb-multiarch command line and in the (non STMCube-ified) Eclipse CDT
Alternative GDB Servers
You could try STLink open source. I did. The problem is, your device might not be supported properly. I built 1.6.1 from Github to enable support for STM32G03x device. While moving to this version enabled it to detect the device, and I can use st-flash to program the device, the debugger is unusable (try and alter a register, it alters the wrong one, try and single step a program, it crashes immediately).
Do try it though .. it's easy and quick to install (or build), so it's worth checking if your device will work correctly with it.
Openocd is another option, but seems not to support SWD connection. I tried a build that allegedly had a patch for this but no luck.
If you can get one of these open source alternatives to work, they have another advantage, you may be able run them on something like a Raspberry PI, which means you don't have to get a PC physically close to your target.
Run the GDB server from STMCubeIDE in isolation
For Windows, see the OP's answer. For Linux, I do this alter the pathnames to suit your installation
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/user/apps/st/stm32cubeide_1.5.1/plugins/com.st.stm32cube.ide.mcu.externaltools.stlink-gdb-server.linux64_1.5.0.202011040924/tools/bin/native/linux_x64/ /home/user/apps/st/stm32cubeide_1.5.1/plugins/com.st.stm32cube.ide.mcu.externaltools.stlink-gdb-server.linux64_1.5.0.202011040924/tools/bin/ST-LINK_gdbserver -p 61234 -l 1 -d -s -cp /home/user/apps/st/stm32cubeide_1.5.1/plugins/com.st.stm32cube.ide.mcu.externaltools.cubeprogrammer.linux64_1.5.0.202011040924/tools/bin -m 0 -k
How did I get to this? Firstly launched a debugging session from STMCubeIDE, then ran
ps aux | grep gdbserver
Then we can see how Eclipse (STMCube) is launching the gdbserver and work from there.
If you find it complains about a .so file, locate that file from the STMCube installation and ensure the path to the directory containing it is in LD_LIBRARY_PATH (as per my example)
You can also launch the program with --help to show more options.
If add -e (persistent) you can disconnect and reconnect a GDB client without resetting the target (it will reset on initial invocation of the gdb server though, even without -k).
GDB Serial
This is where the target implements the GDB server end of the protocol. The GDB stub usually runs in an exception handler. This would usually be your breakpoint handler but you can also make it the default handler for unhandled exceptions, or, for example, the ctrl-c interrupt.
I have done a lot of Googling about this recently and basically when people ask about it on forums they usually get responses along the lines of "Here be dragons" or "Why don't you use JTAG?"
So the drivers for this, you might like to know, are in the GDB sources git://sourceware.org/git/binutils-gdb.git under gdb/stubs. The documentation is here. There isn't a stub implementation there for arm. Which is sad really, I used to use GDB remote serial regularly where I worked, and some of those targets were indeed ARM. The operating system was ecos.
So could ecos GDB stubs be ported to bare metal? Having giving it a good coat of looking at, I believe yes they could. The stubs are based on the ones from the GDB sources but they are heavily polluted with Ecos and Redboot build macros and copyright (the ogiringals were written by HP and released without copyright). We don't know what bugs the Ecos stubs may contain (I fixed at least one back in the day and I don't recall whether I submitted a patch). We don't know if they really support the latests architectures properly. And, we don't know if, after that, they simply use up too much memory - my STM32 has 8K of SRAM and I already see buffers that have a default size of 2K (not saying that's necessary but you see how work needs to be done here..)
So this third option, I will revisit this one day but for now, for me, it's a nope.
I have been tasked with setting up a development environment for an embedded platform. So far, I have set up a remote build host in NetBeans, which copies all of the source files to the target device, compiles them natively with the GNU toolchain on the device (g++, ld, etc.), and then runs the compiled binary and forwards stdout to the development machine that NetBeans is running on.
What I don't understand is: How does the binary on the build machine know where and when to start/stop if the breakpoints exist only in NetBeans? The build host only required ssh access and a compiling/linking toolchain, but somehow seems to communicate with NetBeans for debugging. A colleague of mine suggested it uses gdbserver, but I have not found any documentation on the NetBeans website about this package, and it is not installed on the build host (at least not from apt). How is NetBeans doing this?
GUI IDE's which use (or can be configured to use) a distinct command-line toolchain for compilation and debug typically do this by running each required toolchain program as a subprocess and interacting with it through standard streams. Essentially, the IDE would use gcc or gdb with the same textual interface used when running it in a terminal window. The IDE uses its knowledge of lines in the source file to configure breakpoints in gdb much as you would while running it by hand.
In your case, the IDE is configured to use a "remote host" for all of this, so instead of being invoked locally, the toolchain is controlled through as ssh session to the remote machine where both building and running occur.
Because the gdb debugger and the target program are running on the same computer, no gdbserver is required.
In the cases where gdb is too large for the target system, gdbserver is a small program which often gets cross-compiled for the target and loaded onto it. This serves as a compact little delegate which talks to the main gdb program running on a build machine via a serial or network connection and performs the raw interaction with processor, memory, and running program on behalf of gdb.
Another possibility is that the gdbserver role is held by a helper program running on the same machine as gdb which instead commands something like a JTAG debug adapter to interact with the target hardware at a lower level. In this case however, the helper program implementing the gdbserver protocol is not usually called "gdbserver" but instead has an implementation specific name, for example openocd.
gdb runs on the target machine. Only communication with gdb (commands etc) goes via net to your local machine. Read gdb documentation if need to know more/
You can do exactly the same - just open the remote terminal , run gdbserver, start gdb and you are done :)
TL;DR: is there a step by step tutorial to do remote code debugging using Eclipse Neon?
I have the source code in a Linux machine with a GCC dev environment. Normally, I ssh to the box, edit the file, and compile/debug using gdb, and it works, but it is a bit clunky for me.
I am now trying to debug the code from my Windows machine using the latest Eclipse version (Neon as of this writing).
I've tried following the instructions online (like this one), but they all seem to point towards (cross-)compiling the code locally, deploying it remotely and debugging there. This is not what I'm after. I essentially want to use Eclipse as a remote text editor+gdb interface, with the building and compiling being done in the remote system.
I've installed CDT, plus pretty much any plugin remotely related to remote development
Remote System Explorer
Remote Launch
GCC Cross compiler support
Remote (over TCF/TE) Run/Debug Launcher
Direct Remote C++ Debugging
TCF C/C++ Debugger
TM Terminal
So far, I can connect to the remote system, create a Remote Project and edit the source code.
I don't need Eclipse to compile the code (I can do that separately) but I'm unable to debug the code.
Using C/C++ Remote Application fails in many creative ways when trying to find gdb in the remote system.
Using GDB (DSF) Automatic Remote Debugging Launcher ends in a java.lang.NullPointerException, which also invalidates the configuration
Using Direct Remote Debugging Launcher asks about a remote workspace, then complains with "Error with command: gdb --version Cannot run program "gdb": Launching failed"
Remote Application complains about the Process/Image field. Setting it to the binary output doesn't enable the Debug button, so no dice.
TCF is dead in the water. It doesn't recognize the SSH connections I set up on RSE, it asks for the username password (I use public keys) and root password (?!) Even when entering that info, it fails to continue.
On a whim, I tried NetBeans, and followed the instructions here, and got it working in five minutes. The mode I'm following is the "Full Remote Development" according to NetBeans. The reason I'll still need to stick to Eclipse is that it is the dev environment that we use in the company, and it makes little sense to me to add another IDE to do something that Eclipse by all rights should do no problem.
What I find is that the walkthroughs for Eclipse I've found are either
Using plugins that are now either deprecated, not supported or have been completely reworked. Eclipse crashes and burns on these.
Trying to compile locally and deploy remotely, doing things like embedded even, but that's not what I'm looking for.
Using the Eclipse DStore client-server combo, which is essentially an alternative to SSH, but not what I'm looking for either.
I'm then hoping someone has written/found a tutorial that is relatively simple to follow (it is, after all, a relatively simple thing to do, as NetBeans has proven), and that works on any version of Eclipse.
I'll consider using an older version of Eclipse, but if so, please be specific in which version I should use, and which plugins I should install.
I am currently working with the Xilinx Platform Studio(XPS) tool to make an automated design with command line tools (without using GUI). I know how to build project using XPS in GUI mode, but don't know how to build a project with command line tools. I got some information about the command line tools usage from the "Embedded System Tools Reference Manual" and the "Command Line Tools User Guide".
But, I didn't get any information about following things:
How to select Bus interconnect type.
How to select Clock
How to select processor
How to select BRAM memory
How to make signals external
How to import our peripheral
How to select address
I did all the following steps in XPS command line
Creating a new .xmp project
Adding architecture, device, package speed
Language setting,simulation setting
loading ucf file
I don't know how to add peripheral, processor and interconnect bus type.
I am struggling at this stage only - I know how to synthesize, implementation, and Bitfile generation.
If anybody knows information about these things using command line tools or any documents, Kindly reply to this post
I am afraid I do not know how to do this in XPS, but with Vivado all of these actions may be done via Tcl commands. Vivado works so much better than XPS. Unfortunately, Vivado does not support older Xilinx devices, so this may not be an option for you.
I'm developing a program for a specific environment. That means it needs to run on the OS and compile using its compiler. I have a different environment at home (Windows 8) is there a way Netbeans can be used to connect to the target environment and use its compiler? It is enabled for remote login.
So basically right now I write code on my home computer, connect using Putty to the target computer, copy the source code over, compile it and run it. I'm trying to simplyfy this process so I only have to use Netbeans.
Why don't I just get same compiler and do everything locally? The target computer is running Linux and the program has a lot of system calls.
I know Aptana has a simillar feature, but Aptana is so crappy in general I don't want to use it.
Let me know if my question doesn't make sense and I'll try and reword it.
Yes, you can do remote development in NetBeans. It's described in its Help subsystem: