Electronics > Microcontrollers

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

(1/3) > >>

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.

Navigation

[0] Message Index

[#] Next page