stm32 Cube Programmer Window does not close

[Greg Horler]

I have downloaded the latest version of Cube Programmer and updated my ST-LINK/V2 firmware. I've tried to program connect with a target I have designed and the target cannot be found. Clearly I need to find out why, but that is not my question. Rather, after this, the Cube Programmer application will not close, nor can I find it in TaskManager to kill it! Is this a known bug? Having to restart my machine each time this happens is a pain. (BTW using windows 10

Many thanks

[Nesrine.JLASSI]

Hello @Greg Horler​ 

Could you please tell me which Board do you test with.

Best regards,

Nesrine

[Greg Horler]

Nesrine, hi.

I have a STM32-L082 soldered to a lqfp21 beakout board; connections are as follows

.Pins 32 and 16 connected to GND (Vss) Pin 3 OF STLINk/V2

.Pins 1, 5 and 17 connected to 3.3V (Vdd) Pin 2 OF STLINk/V2

.Pin 4 connected to (Vdd) via 100k BUT NOT connected to STLINK/v2 (Taken from nucleo schematic)

.Pin 31 connected to (Vss) via 100k BUT NOT connected to STLINK/v2 (Taken from nucleo schematic)

.Pin 23 connected to SWDIO, Pin 7 OF STLINk/V2

.Pin 24 connected to SCLK, Pin 9 OF STLINk/V2

While any advice on the above would be greatly appreciated I don't understand why you need this? Surely the control of an application, interms of exiting it, should be independent (or over-ridable) for any hardware interface connections. It is the fact that the app cannot be forced to close that is the problem.

Thanks for your willingness to help

G

[Greg Horler]

UPDATE ON MY OWN QUESTION, that is yet to be answered!

I have managed to get my "home grown" target working, and this allows me to program my device etc and interrogate it with the ST Cube Programmer. If I can communicate with the target, the Programmer program behaves as it should, i.e. I can close the window to exit the program. However If I induce any fault that means the target cannot be accessed (e.g. remove power to the tagrget), the Programmer software hangs and cannot be closed in the normal way (clicking the x button) and cannot be killed using the task manager. I find this very odd and suggests a bug? Having a program that allows the target device to be interrogated is an important first step in ascertaining and verifying communications with a new board (target) design. However, not being able to close the program if comms have not been made with the target is a serious flaw. Has anyone else observed this behaviour of the CubeProgrammer and ST-LINK/V2?

Many thanks

Greg

[AToog.1]

Hi Greg, Yes I have the same issue, can't connect then I can't close the app and can't find it list in Task Manager to close it. It must but under some odd name. Doesn't look like we are going to get much help here they could at least acknowledge an issue and tell us what it is called in Task Manager.

ST link v2 used to be flawless but since the latest upgrade it does not work with the STM32 programer but does half the time with the old ST link utility.

Did you make further progress?

[AToog.1]

If it helps you can find it under Task Manager its under "Java"

Have to end it twice to kill it

[Tesla DeLorean]

Runs under Java JRE, need to look at versioning of that, and perhaps interactions with AV software. These aren't "native" applications.

Going to be real hard for others to diagnose a "doesn't work / me too"

Perhaps need to focus on what is common on systems that fail. Especially where the is a subset of succeed and fail cases.

Also Windows is notorious for having misbehaving kernel level drivers that can deadlock, or block user applications.

Have a long standing problem on a multi-core AMD system with ST-LINK VCP / FTDI VCP / ClearTerminal.

Issues with the ST-LINK drivers would need someone with a kernel debugger.

[HWu.19]

it works, thanks!​