STLINK-V3 MINIE V3J16M9 Firmware "STM32 Deubg+VCP" configuration non-functional VCP

[JohannesWilde]

For the last several days I have been trying to get the virtual COM port [VCP] of my STLINK-V3 MINIE to work together with my NUCLEO-H755ZI-Q. After realising that the VCP_RX/TX pins are not connected to the MIPI10 connector CN5 and thus soldering on my own cables and measuring the signal using an oscilloscope [confirming the signals were the expected 3.3V], I thought it should work.

However - even though the VCP was detected under Windows 11 and I double-checked the connection settings in my terminal application - I did not get any communication.

The solution seems to have been, to reprogram the V3 MINIE with the "STM32 Debug+Mass storage+VCP" firmware [Version V3J16M9]. After that it worked flawlessly [without changing anything else]. Previously the "STM32 Debug+VCP" V3J16M9 firmware version was flashed to it.

So my question is:

- Did I overlook some configuration option?

- Or is this a problem with the firmware and I should try to contact ST?

PS: The STLINK-V3 MINIE was bought quite recently - the sticker on it says "MB1762-V3MINIE-B01 K250401102".

[S C]

Hello,

I have no explanation for your symptoms. The fact that in both cases, V3J16M9 is involved makes strictly no difference regarding the VCP features. The only difference induced by the mass storage activation is the attempt by the STLINK-V3MINIE to connect during its startup to the target, to identify it and configure the mass storage interface. It may also have indirect impacts on the target, but I do not see what could explain a difference in the VCP behavior afterwards.

I'm wondering, instead, about the overall context of your case. Why using an STLINK-V3MINIE through CN5 while you have a STLINK-V3E onboard on the NUCLEO-H755ZI-Q with the VCP natively connected ? It's not an expected use case (that's why signals are not provided on the mounted connector), moreover there might be conflicts on signals (would need to look at the board schematics). Have you tried communicating with the VCP of the embedded ST-Link without any external probe connected to CN5 ?

[JohannesWilde]

Hi there,

thanks for getting back to me.

1. Yes, I would have thought, enabling the mass storage option should not make any difference for the VCP, as well.

2. I tried to use the CN5 with the STLINK-V3MINIE as the latter was not communicating via VCP with my custom board - and I wanted to have a known working reference and thus fell back to the DevBoard. The VCP of the embedded chip on the DevBoard did work and I did not see any conflicts in the schematics - but the V3MINIE's VCP did not work. At least, until I changed the firmware to the one supporting the mass storage option for the V3MINIE.

Would you be able to reproduce my setup?

Beste regards

Johannes

[S C]

OK I just had another idea: the V3MINIE embeds level shifters, requiring T_VCC to be supplied in input. May you please double check in the failing cases that the signal is OK at V3MINIE side ? This can explain VCP failures (but still no direct link with the mass storage interface ...)

[TDK]

Unable to duplicate here.

Note that the COM port changes when you change the device type and you may need to disconnect/reconnect the terminal before it shows up.

[S C]

@TDK, right, the COM port ID changes because each device type has its own USB PID and Windows uses it (among other things, like USB serial num) to compute the port ID. But it not expected to have any impact on the VCP flow afterwards, excepted if (of course), the parameters associated with this COM port change on host side (perhaps another thing to check by JohannesWilde ?)

Thank you

[JohannesWilde]

Hi TDK,

thanks for the comment. I did have to change the virtual COM-port selected on Windows for the communication as well. Yes. But I did that.

I did use hterm, pressed the "R" [refresh] button, selected the respective COM-port and pressed "connect".

Best regards

Johannes

[TDK]

You know what, I'm using an STLINK-V3MINI to test this, not a STLINK-V3MINIE which I don't have on hand at the moment.

If my memory is correct, this exact issue was present in previous versions of the firmware for various st-link programmers, but it was fixed. It wouldn't surprise me if it crept back in. There are a few threads on it but I couldn't find them quickly.