Command line unit tests causing inability to run tests a second time

[dabramson]

I have unit test project done with the TinyEmbedded framework. I’m able to run unit tests over and over again without issue from the Visual Studio Test Explorer; however, executing unit tests via the command line only works once. If I attempt to execute by command line a second time I get an error in a message box with the following text (“read version failed” is the error):

C:\Users\tfsbuild\AppData\Local\VisualGDB\EmbeddedDebugPackages\com.sysprogs.arm.openocd\bin\openocd.exe -c "gdb_port 59883" -c "telnet_port 59884" -f interface/stlink-v2.cfg -f target/stm32f4x.cfg -c init -c "reset init" -c "echo VisualGDB_OpenOCD_Ready"
Open On-Chip Debugger 0.10.0 (2018-05-24) [https://github.com/sysprogs/openocd]
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
WARNING: interface/stlink-v2.cfg is deprecated, please switch to interface/stlink.cfg
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 2000 kHz
adapter_nsrst_delay: 100
none separate
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : clock speed 1800 kHz
Error: read version failed
in procedure 'init'
in procedure 'ocd_bouncer'

Furthermore, after one execution of unit tests via the command line I can no longer connect to the target with STM32 Link Utility, and I can’t run unit tests from Test Explorer (it gives me the same error as from the command line).

This is output on the console at the end of the first command-line execution, maybe it has something to do with the issue:

Waiting for the test process to exit before building a coverage report....
VisualGDB: Warning: Timed out waiting for target to exit. Code coverage report may be inaccurate.
Finished running tests.

 

The only ways I have found to recover from this problem is to disable and re-enable the STMLink Driver through Device Manager, or physically disconnect and reconnect the st-link from the PC and power cycle the target.

 

[support]

Hi,

It looks like the command-line mode might be leaving ST-Link in a state where it doesn’t respond to regular commands. A short-term workaround would be to simply plug it out and back in.

Long-term, please let us know how to reproduce it. Are you simply using VisualGDB.exe /runtests, or some other way to run the tests?

[dabramson]

Hi,

So I have upgraded the ST-Link firmware and only seen this error once since then. I’ve also tried it on a different PC and did not have the issue there. The two PCs have different windows versions (7 on the one with the error, 10 on the other), and also different STM driver versions.

I’m thinking there is something funny going on with versioning, so I’m going to make sure all of the STM software is at the latest versions on all PCs. If I still see the issue once I have less variables to deal with I’ll report back here.

Thanks,
Dave

[support]

Hi,

Good to know it works. If you encounter any further problems, please do not hesitate to contact us again.

[Author]

Posts