I'm working on safety-critical software that requires extensive testing. The target processor, a Cortex-M4, has rich resources for the application but the unit and integration tests, if aggregated, would be much larger than the on-board FLASH/RAM. They are designed to be run from gdb while using semi-hosting to off-load the test results. What's needed is a way to automate the testing so it can be run without per-test human intervention.
The test programs run fine from Eclipse using both OpenOCD and Segger debugger front-ends. These require per-test configurations and then manual starting of the tests. There will be 30-50 test programs so this isn't really viable for continuous integration or simple batch runs.
I've been looking around for possible ways to do this. There are a few tricky bits to consider. The first is supporting the semihosting of the output. That uses the breakpoint system to have the I/O from the host. In this use, a couple of files get opened on the host computer for logs. Another issue is ending the program being tested and loading the next. The programs can take a long time to run and drop into an infinite loop when the main() is exited. And the development platform is Windows 10.
The two basic ideas I've had are to use the gdb client library from cygwin to create a custom program or to use OpenOCD. Running through multiple tests could be done inside the application or from a Makefile.
Question: is the semihosting done in the gdb client or server?
So... Looking for some suggestions or experiences in creating what I picture as a custom gdb client in Win10.
Related
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.
I have a C++ library that I want to include into my iOS application. It has unit tests. If I put it simply, it's something like:
#include <cstdio>
int main()
{
printf("Test result\n");
}
Is it possible to run such an application that uses only stdin/stdout on an arm64 based iOS device to make sure that all compiles and works correctly?
I can do it on a real android device with adb push/adb shell, so I wonder, is it possible to do the same on iOS based devices?
It's not completely clear what are you trying to archive. But let me guess:
There is a third-party library you don't have control over.
There're tests in this library. The tests are a separate console app.
And you're looking for a way to run this app in some kind of shell on iOS that can run an arbitrary executables. And you can't because of all the security.
But if you have the source code of unit tests, then with some small changes you can compile them as a library, not as an executable. And call them from a "shell" you can write yourself - a small host app the sole purpose of which is to call these tests (and probably send their results via any kind of connection that suits you).
More on this you can read here
Yes, this host app will have a GUI, but I don't really understand why do you against it... if you really are.
Also these may be helpfull:
debug bridge for iPhone / shell command prompt
ADB equivalent for iOS device
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 see that only 3 test projects exist.
Coded UI Test Project
Unit Test Project
Web Performance and Load Test Project
I have setup a .testsettings file for my solution that enables Network Emulation (link)
In order to start up network emulation I have to run one of the test projects listed above, all of the above test projects are designed for automatic testing. I want to be able to debug and test my project(s) manually while Network Emulation is on, currently the only way to do that is to create a Unit Test, start it, and then just call the other projects Main method (that I want to manually), the problem with this is that sometimes the program's UI does not show (unit test debug mode it does not - I am unsure why). Unit testing was not designed for such a thing anyway.
So really, is there a way to enable Network Emulation while I debug normally, or manually enable/disable the network emulator in the background for when I need it?
For those that don't know, Network Emulator slows down traffic in/out of the machine to emulate real networked environments, it automatically starts up on the default network adapter when a test starts and closes when a test finishes
Thanks
I decided to write my own small program that starts up the emulator without the need of visual studio testing/visual studio opened. For anyone that is interested it is based off this post:
http://blogs.msdn.com/b/lkruger/archive/2010/04/07/stand-alone-network-emulation-and-codeplex.aspx
Code is here:
http://teamtestplugins.codeplex.com/
"local continuous integration system" may not be the correct term, but what I'm hoping to find is an continuous integration system that can be configured to monitor changes to local files (C++ files in particular) and 1) try to compile the affected object files (stopping on first failure), and if successful and no new source file changes 2) link the affected binaries, and if successful and no new source file changes 3) run affected tests.
By monitor changes to local files, I do not mean monitor commits to a revision control system, but the state of local files as they are saved. Ideally the system would be provide integrations into source editors so it could monitor changes in the editor that haven't even been saved to disk yet.
Ideally it would also provide a graphical indication (preferably on Windows 7) of current and recent status that quickly allows drilling into failures when desired.
The closest thing I found was nose as described here but that only covers running Python tests not building C++ files.
The closest thing to what you are looking for is cdash and the Boost test bench; I think that a tool like the one you are looking for will never exist for C++ because compiling each project after editing a single file it's only a waste of time in a productive C++ workflow.
Continues Integration is a rising concept today, so you are not alone here.
Assuming you are developing on Windows, if you are working with Microsoft Visual Studio
you may consider Microsoft's Visual Studio Team Foundation Server (TFS)
(formerly Visual Studio Team System).
That will give you Source-Control AND Build-Automation in one package,
with great integration to Microsoft products, of course
(I think there is a free version for MSDN users).
If not keen on Microsoft products, or just looking for build-automation,
I would recommend a great Open-Source Continues Integration tool:
Jenkins CI.
Good luck!
I would look at Jenkins CI - it is a good tool, works on any platform, and can be configured to do almost anything. I used it to run Python Code that talked to a mobile phone, made calls and recorded those calls (and tested the "quality" of the call, although my project never got the £xxxx real quality software, as we were just showing a concept), and then Jenkins would produce graphs of "how well it worked".
You can also do what you describe of "chaining" - so it would discover that your source has changed, try to build it [generally this is done using make, so it would automatically stop at the first errored file (although it could be hundreds of errors in one file!)]. Compile and build success then chains to running tests. Not entirely sure how you determine what is "relevant". If your test cycle isn't enormous, I'd run them all!