STLINK V3 - is it supposed to be 100% reliable?

[PHolt.1]

I have just moved from ST-LINK/V2 ISOL to STLINK-V3SET. Win7-64. 24GB RAM. A very stable machine and I have two identical ones.

The reason for V3 was to see if the SWV ITM debug mode was more reliable (or occassionally loses a byte or so), and I read somewhere that V3 is much faster.

Well, V3 is much faster. Code download has gone from a few seconds (~200k) to something so fast I can barely see it. This is worth having especially in a production environment, and especially at 24MHz (which is what it turns out to use if you select Auto)

But it isn't all that reliable. After some minutes Console says it has lost contact. At 8MHz it seems to be more reliable but only sometimes. I guess the quality of the wiring comes into it... I have about 30cm which is 20cm ribbon cable and 10cm single wires to my PCB. But even 8MHz is not 100% reliable. It is much better on one PC than another. All speeds are 100% reliable for code download (well, it always reports as having verified) but in the long run with debugs it does eventually bomb out. I tried the debugger at 1MHz instead of 2MHz but it makes no difference.

I am using SWV ITM debug because it is very fast.  I did a printf("1234567890") and timed the gap with a scope between two pulses generated before and after.

SWO debug / SWV ITM data console: 6-20us

Dynamic Printf / debugger console: 120ms!

Should I just accept that this stuff is a bit flakey and live with it? STLINK-V2 was solid in terms of the connection to the debugger, whereas V3 eventually loses the connection.

If anyone can suggest anything else for me to try I would be very grateful.

The other modes in the screenshot e.g. JTAG do not work, which is weird since JTAG is what this whole thing is supposed to be using. Only SWD works. The target connections are

JT-SWCLK

JT-SWDIO

NRST

JT-SWO

JT-NJTRS (no connect)

https://peter-ftp.co.uk/screenshots/20210420163062416.jpg

[Vangelis Fortounas]

Hello

Wrong GrouNDing may be a reason for such behavior.

I use V3-SET and only at 24MHZ Never had an issue with clock speed.

[Uwe Bonnes]

Bad USB cables and connectors are also often an issue.

Otherwise, flashing for most devices is limited by the flash speed and rarely by the debugger.

[Andreas Bolsch]

Hm, I've used an V3-Set without any problem, transferring hundreds of MBytes in a single OpenOCD session at 24 MHz SWD clock without any problem. Simple jumper wires to a Nucleo-H743ZI (the old one which doesn't have an internal V3) ...

[Andrew Neil]

"I guess the quality of the wiring comes into it"

Indeed.

"I have about 30cm"

That does sound on the long side; also, as @Vangelis Fortounas​  said, good grounding is important.

"and 10cm single wires to my PCB"

A proper, short, direct ribbon cable would be preferable.

https://documentation-service.arm.com/static/5fce6c49e167456a35b36af1?token=

via: https://developer.arm.com/documentation/ka001776/latest

note that these can be purchased off-the-shelf as standard assemblies

What voltage is your target running at? The V3 has a much narrower range than the V2 ...

[PHolt.1]

Thank you all for your input.

The funny thing is that on the computer where it works perfectly at 24MHz (and has been connected for 2 days now) has a very long USB cable (extended to about 5m) and has everything else the same as the less reliable installation.

The only obvious thing that differs is described here

https://community.st.com/s/question/0D53W00000jkapcSAA/where-do-i-configure-the-gdb-server-log-level

and I wonder if there is some hidden config in the GDB debugger script file (the debugger seems to be a command line tool, and the Cube IDE debugger config form seems to set up this script file, but does not give access to all of it via the form) which has been created differently.

For example I changed from GDB to Jtag to see if it works better (Jtag didn't work at all) and tried various different things, but eventually I put everything back.

The final situation is that on the "non working" installation the code download doesn't work - it gets stuck at "97%".

I am changing the target PCB to incorporate the 10-way "10 pin Cortex debug connector" (the one on which pin 2 is DIO and pin 4 is CLK) for which a cable is included with STLINK V3 which should tidy up the connection in terms of impedance. The header for this is a 0.050" one, 2-row.

[Pavel A.]

You wrote that the PC is Win7. Does the ST-LINK work there in USB 3 mode?

​Note that Win7 does not have native USB3 host drivers, so the problem may be in 3rd party USB3 driver.

Try Win10 or Linux.

Or connect the ST-LINK over a USB2 hub (lower speed of course).

--pa

[PHolt.1]

That's a good point. One the "working" PC I am using a motherboard USB2 controller. No USB3. On the "97% working" PC I have a USB3 hub with drivers. I will try a USB2 port on it.

USB2 should be way fast enough for this stuff.

Both motherboards are EX58-UD5.

[Tesla DeLorean]

To be honest ST's use and implementation of OpenOCD doesn't seem to be particularly robust, but we obviously hear more from those with issue, than those who quietly succeeded.

I've found the ST-LINK/V3 VCP particularly to cause lots of issues on multiple processor Win7 boxes (6 Core AMD Phenom, 8 Core Intel Xeon) where Terminal applications can crash the kernel with SiLab and FTDI VCP. Seems to mostly relate to scanning/probing available COM ports when first opening. But it totally frosts the machines, requiring a power off/on cycle.

[RMaia]

I found out that in some PC's I have the debug probes don't like being plugged to USB3.0 ports or even USB hubs. I've had better results plugging the cable directly to a "native" USB2.0 port stright from the motherboard...