10-pin debug connector and STLINK-V3-ISOL - not reliable?

[peter-h]

I am using STLINK V3 with the ISOL board, and using the supplied 10-core cable, going to this connector in my 32F417 target



On the target connector, I have pins 3,5,7,9 grounded.

Pins 2,4,6,10 go to CPU pins PA13,PA14,PB3,NRST.

It works, but reliably only for code download. If I try to run SWV ITM data console, that also works but very soon I get a loss of comms. I am running at 8MHz; the ISOL debugger can go up to about 15MHz before it fails. I tried it at 1MHz but the same happened.

The wires to the CPU are pretty short - 5cm max.

I would be grateful for any ideas.

The connector in the STLINK V3 is this, and the yellow shows the subset which they bring out on the 10-way cable, which seems to be a standard pinout for ARM debugging



It can't be far off because I can set a breakpoint with a 1000 ignore count and that works, so thrashing the SWO debugger doesn't break it. This is the Console output showing the error:


Download verified successfully


 ------ Switching context -----
Target connection mode: Default
Reading ROM table for AP 0 @0xe00fffd0
Hardware watchpoint supported by the target
Failed to set com freq, status 0
COM frequency = 8000 kHz
ST-LINK Firmware version : V3J7M2B4S1
Device ID: 0x413
PC: 0x8025688
ST-LINK detects target voltage = 3.25 V
ST-LINK device status: HALT_MODE
ST-LINK device initialization OK
SWV_SetStatus(true): stop_reply_pending == 0
handle_vCont_c, continue thread
ST-LINK device status: RUN_MODE
ST-LINK device status: HALT_MODE
SWV_SetStatus(false): stop_reply_pending == 1
TraceCaptureStart and SWV event set to APP_FALSE (0)
NVIC_DFSR_REG = 0x0000000A
SWV_SetStatus(true): stop_reply_pending == 0
handle_vCont_c, continue thread
ST-LINK device status: RUN_MODE
ST-LINK device status: Failed to get status, Target not responding, retrying... 19
Target is not responding, retrying...
ST-LINK device status: Failed to get status, Target not responding, retrying... 19
Target is not responding, retrying...
ST-LINK device status: Failed to get status, Target not responding, retrying... 19
Target is not responding, retrying...


Let me add that using the same debugger but using the big 20-way cable, to the same CPU pins, works 100%. This suggests the ST LINK V3 ISOL has a problem with the connection for the 10-way cable.

Update: I have it working but only by removing the MB1440B board and connecting the 10-way cable to CN1 on the board below - the MB1599B ISOL board. Both of these boards have the CN1 connector (for the 10-way cable) and they stack directly one above the other, but it looks like MB1440B affects the signals on its CN1, while the signals on its 20-way connector are fine. So basically if using the 10-way debug cable, you don't want to be using MB1440B.

To re-phrase it: There seems to be a fault on the MB1440B board, when stacked on top of the MB1599B board (the ISOL board). The 20-way connector, CN2, works but the 14-way (CN1, which is used for the 10-way cable) does not. Well, it works but with a lot of intermittent faults. The solution is to not use MB1440B and plug the 10-way cable into the MB1599B board instead (CN1 also).

Maybe this will help somebody one day, who wasted a day of his life trying to get a solution on the mostly useless ST forum

 

[ajb]

Interesting that you found the issue is related to the isolator board.  I haven't used the ST-LINKv3 but found the v2 to be quite flaky, with debug sessions or programming cycles randomly failing until I unplugged and replugged the USB, so it wouldn't surprise me if it were purely a software issue with the tool.   

[peter-h]

I have designed a lot of isolated comms products so expected the ISOL board to slow things down to some extent, and sure enough the "24MHz max" product, when the ISOL board is installed, goes down to something like 10-15MHz, and is best run at 8MHz.

But why the 20-way connector works while the 14-way (10-way) connector doesn't, is a mystery since they are the same signals, same PCB tracks. Could be something marginal.

I think ST did not expect people will be sandwiching the ISOL board between the debugger board and the board with the connectors on it, but you have to do that if you want the big 20-way connector. And that works. And it is much faster for both code upload and stepping through than the STLINK V2.

I found the V2 to be solid, although I used only the 20-way connector because that's all it has.

[peter-h]

The mystery deepens somewhat since one of the devices on the ISOL PCB is a DC-DC converter, ADUM5020. So it may be that target power is not needed. The documentation is silent on this.

This shows the setup

[abyrvalg]

A related idea: if your reason for isolation is PC-target ground level difference - you can isolate the other side, USB (there are cheap ADUM3160-based isolators on AliExpress). I’ve tested such setup (ST-Link V2 + isolator, both from Ali) and it worked fine.

[peter-h]

Yes; a very good Q.

I am going for isolation just to make stuff harder to blow up

[Doctorandus_P]

Just adding isolation is no guarantee that it's more robust.

I was once tempted to buy an "AVR Dragon", but a bit of research revealed that the thing had a strong tendency to release it's magic smoke if there is any under voltage condition on the USB bus. The thing just kept on drawing more current until a tiny on-board SMPS blew up. Using that thing with an USB isolator that has a small power supply might trigger just this condition.

The recommendation was to always power the "AVR Dragon" from a powered USB hub.

[abyrvalg]

Define "robust". Which part of the setup are you trying to save? In my setup 4€ st-link and 5€ isolator are expendables and PC is the part I’m trying to save. In st-linkv3+isolator board the expendable part is isolator board (what’s the price? more that 9€ I guess).

[peter-h]

I am in industrial datacomms and there is a vast difference in how much stuff gets blown up, non isolated versus isolated.

Just takes a bit of static.

The STLINK V3 SET is about £30 (Mouser) and the ISOL board is another £30.

I don't want to blow up the PC or the target. The PC because it is a huge hassle to change the motherboard (yes one should use a hub, preferably a powered one because the STLINK might well draw a bit more than the max allowed of 0.5A). The target because it is a prototype, SMT, had to be hot air soldered, took days to build four of them, and I have only the four made up. I have one at work, one at home, someone else has one...

And eventually we will be programming these in production and then it really must be robust.

The USB power is a very good point actually. I never use an unpowered hub (except for a laptop and mice and such).

However the key issue is why the 20-way cable connection works 100% while the 10-way cable connection works for code download but only just hangs in there for debugging, and hangs in there "almost 100%" if you use the connector on the board further down (which is still isolated; the 10-way cable is being plugged into the ISOL board directly). Basically it means you can't have both the 20-way and the 10-way (14-way on their PCB) connectors available on the same debugger, unless doing just a quick code download+verify. I posted this in case it helps somebody in the future.

But hey a lot of this ST stuff is flakey. Their libraries are full of crap (USB, ethernet), their GDB stuff is flakey (I've just spent a few hours setting up the project on a laptop, what a lot of fun it was to get ST Cube to open the project directory, and it took a number of reboots and messing around to make the debugger connect; kept coming up with that stupid joined drive error which is aaaaall ooooover the internet in the countless STM forums, with no solutions), Cube IDE is weird in so many little ways (have to do Clean Project / Build Project / Rebuild Index / etc). When it works you don't want to touch it

[peter-h]

Update:

I never solved why the 10-way conn on the ISOL board is unreliable, but with this adaptor+cable from Olimex



plugged into the 20-way connector, and into the 10-way one in the target, it seems to be very reliable.

ST would not supply the circuit diagram of that last PCB (MB1440) which is silly since it is mostly passive...
https://community.st.com/s/question/0D53W00000pSjJVSA0/mb1440-circuit-diagram

[peter-h]

Thank you.

I think I am ok with the various pinouts. As you say, the info is out there, all over the place.

There is just something about this ST board which makes the small connector unreliable while the 20-way one is OK, and I don't believe it is the different ribbon cable pitch.

[Jester]

Interesting that you found the issue is related to the isolator board.  I haven't used the ST-LINKv3 but found the v2 to be quite flaky, with debug sessions or programming cycles randomly failing until I unplugged and replugged the USB, so it wouldn't surprise me if it were purely a software issue with the tool.

My experience as well, something is very marginal with these devices. In the past when I have debugged bad hardware or software that was as marginal as this device is ( I tried more than one) when I tracked down the problem I was left wondering how it worked at all or was amazed that it worked as well as it did.