10-pin debug connector and STLINK-V3-ISOL - not reliable? - Page 1
Forum section: electronics / general

author: peter-h
author_rank: Super Contributor
timestamp: May 07, 2021, 07:43:04 am
content: I am using STLINK V3 with the ISOL board, and using the supplied 10-core cable, going to this connector in my 32F417 targetOn 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 debuggingIt 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: DefaultReading ROM table for AP 0 @0xe00fffd0Hardware watchpoint supported by the targetFailed to set com freq, status 0COM frequency = 8000 kHzST-LINK Firmware version : V3J7M2B4S1Device ID: 0x413PC: 0x8025688ST-LINK detects target voltage = 3.25 VST-LINK device status: HALT_MODEST-LINK device initialization OKSWV_SetStatus(true): stop_reply_pending == 0handle_vCont_c, continue threadST-LINK device status: RUN_MODEST-LINK device status: HALT_MODESWV_SetStatus(false): stop_reply_pending == 1TraceCaptureStart and SWV event set to APP_FALSE (0)NVIC_DFSR_REG = 0x0000000ASWV_SetStatus(true): stop_reply_pending == 0handle_vCont_c, continue threadST-LINK device status: RUN_MODEST-LINK device status: Failed to get status, Target not responding, retrying... 19Target is not responding, retrying...ST-LINK device status: Failed to get status, Target not responding, retrying... 19Target is not responding, retrying...ST-LINK device status: Failed to get status, Target not responding, retrying... 19Target 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 V3ISOLhas a problem with the connection for the10-waycable.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 onitsCN1, 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

author: ajb
author_rank: Super Contributor
timestamp: May 07, 2021, 03:45:51 pm
content: 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.

author: peter-h
author_rank: Super Contributor
timestamp: May 07, 2021, 06:19:18 pm
content: 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.

author: peter-h
author_rank: Super Contributor
timestamp: May 10, 2021, 11:01:40 am
content: 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

author: abyrvalg
author_rank: Frequent Contributor
timestamp: May 12, 2021, 02:19:52 pm
content: 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.

author: peter-h
author_rank: Super Contributor
timestamp: May 12, 2021, 02:26:00 pm
content: Yes; a very good Q.I am going for isolation just to make stuff harder to blow up

author: Doctorandus_P
author_rank: Super Contributor
timestamp: May 12, 2021, 10:22:35 pm
content: 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.

author: abyrvalg
author_rank: Frequent Contributor
timestamp: May 12, 2021, 11:24:49 pm
content: 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).

author: peter-h
author_rank: Super Contributor
timestamp: May 13, 2021, 08:17:25 am
content: 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 thekey issueis 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

author: peter-h
author_rank: Super Contributor
timestamp: June 14, 2021, 06:45:45 pm
content: Update:I never solved why the 10-way conn on the ISOL board is unreliable, but with this adaptor+cable from Olimexplugged 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

author: peter-h
author_rank: Super Contributor
timestamp: June 14, 2021, 08:08:22 pm
content: 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.

author: Jester
author_rank: Frequent Contributor
timestamp: July 11, 2021, 11:16:43 am
content: Quote from: ajb on May 07, 2021, 03:45:51 pmMy 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.