# STM32F0 Disco on-board “Cannot connect to target”

So I've already went through these topics:

I cannot access on-board target with the on-board ST-LINK.

Things I have researched:

Computer can detect the on-board ST-Link via USB, but when trying to connect to the on-board target I get the same result from the utility as the first link - "Can not connect to target!" Also tested with the slowest CLK frequency and different modes - nothing. I can see and have measured that the on-board target STM32F0308Rx does 3-4 resets while connecting and then I get that message from the utility.

I have reinstalled ST-Link Utility and manually reinstalled the USB drivers as well. I am on Windows 10 Pro. Also the on board ST-LINK got updated to V2.J33.S0 - maybe I need to downgrade ?

I can access the on-board target with an external ST-LINK V2 - no problems there - I can flash the target and run the code. So I'm guessing there's something wrong somewhere between the on-board ST-LINK and the target but I cannot put my finger to it.

I have double checked the connections from the on-board ST-Link to the on-board target - when jumpers are mounted, the connections are to the correct pins PA13 and PA14 - continuity check is OK.

I have tried to cross examine the Discovery board to the default PCBA pictures found on the internet, it SEEMS that no component is missing or added on the board (I didn't get this board brand new - so I'm not 100% sure what has been done with it). I have all the PCB files at hand as well and so far haven't found anything out of place between design and PCB.

So I think I have exhausted most of my ideas. Anything else I should check ? Or should the target have smth to use the on-board ST-LINK ? I have fully erased the target flash with external ST-LINK.

I really would like to use the on-board ST-LINK - make sure the board is OK, as this saves me a bit of trouble (plan B is to keep using the external ST-LINK)

'###########' EDIT '###########'

I've done probing around the board and Found out that the on-board ST-LINK uC STM32F103 pin 27 is shorted to it's VSS pins. But only that GPIO.

The R14 resistor was also blown to open circuit as it seemed - so I'm assuming that the T_JTMS signal was blown on that micro - thus kind of rendering that chip useless to ever connect to on-board target. Other than that it works.

OR is there any way to configure T_JTMS pin to some other pin with some FW wizardy ? I could maybe also get a new bare chip, mount it on an adapter board, somehow get the ST-LINK FW (I think I saw some custom one on EEVBlog) and flash it with the external ST-LINK? dunno, maybe any other ideas ?

I also had (and still have) this problem (with an ST-Link V2 and STM32F103C8T6 development boards). Although I do not know a real solution, what helps with me is:

• Removing the ST Link from the USB port and reinsert it
• As above, but moving it to another USB port
• Removing the USB power from the development board
• As above, but moving it to another USB port
• If the above steps do not help, start up the STM-32 Link Utility, perform a firmware update (in the ST-Link menu)
• unfortunately haven't yet experienced that different USB ports have any effect. Although could it be that USB3.0 ports could pose some issues? Unfortunately don't have older 'PC USB2.0' available... – crypton Apr 14 '19 at 11:01
• No I didn't try with USB 3.0 ports, just switching USB 2.0 ports. Probably you can check in the System/Device manager from windows if the ST Link is recognized. – Michel Keijzers Apr 14 '19 at 21:08

Given your findings of hardware damage, at a certain point you should face the economic reality that this is a $10 board into which you have expended far more than that in effort. • You can already use it is as with your external ST-Link, you told us as much • You cannot realistically modify the pins used by the stock programmer firmware which is both binary and at least crudely protected • You could load a customizable alternative firmware like blackmagic or CMSIS-DAP, but these will require different programmer software and the later is slower than the ST-Link protocol when both are operating within the confines of USB full-speed USB (fast CMSIS-DAP's like Atmel's are built with application processors having USB high speed to leverage the larger packet size permitted there) • You could replace the STM32F103 with another and with some difficulty finagle the program on there, but the chip itself will cost you about$5 and the time of a person capable of doing this work is worth more than the residual \$5 savings vs. a new board, so it's really only worth it if you have a spare chip on hand and need this board to function in a unitary fashion (vs with the external ST-Link) today.

• Yes, you're absolutely right :), got carried away there :D As I was already debugging, it seemed an interesting challenge, as I've learned always smth interesting from too-much-effort-hacks. Thanks for bringing to my senses. – crypton Apr 19 '19 at 8:51