2022-04-20 06:58 AM
I want to use the STLink BRIDGE API and setup a C++ project. So far the GPIO worked fine, next I want to use the UART. I found the following Warning in the docu: "UART "bridge" is not supported on the STLink USB bridge interface. This functionality is currently provided through a second VCP interface using VCP UART."
How does this work exactly? Has anybody experience and tried this?
2022-04-20 04:37 PM
I think this text means that [modern] ST-LINK devices expose the target UART interface as a separate USB function, so the host applications just use this interface as independent VCP - not via ST-LINK API.
Maybe ST-LINK firmware once had provision to access the target UART interface via its main USB function.
You can tell which VCP on the host corresponds to the ST-LINK (if there are several of them) using host OS specific libraries or APIs.
2022-04-21 01:28 AM
Ok. Thanks.
Are there any plans to update the API to support the Bridge UART as well?
2022-04-25 05:42 AM
One more question: Is it possible to flash/program a target if the bridge is connected? At the moment I have to disconnect the bridge and then I can flash/program. But is there any dll or API where I haven't to do this?
2022-04-26 09:31 PM
> Is it possible to flash/program a target if the bridge is connected?
The ST-LINK DLL (on Windows) works thru WinUSB, and it does not support multiple concurrent applications. So, unfortunately, only one client app can connect to ST-LINK. Either your program or CubeProgrammer.
The VCP function is separate and can be used independently from ST-LINK. This is good.
2022-04-28 12:12 AM
Thanks.
For progamming/flashing I'm uisng the RF-Flasher. Is there no DLL available?
For the STLink Bridge I'm using the STLinkUSBDriver.dll.
So is it not possible to use both DLL's in parallel? For example connect the STLink with the STLinkUSBDriver.dll, do some stuff and then use the program/flash DLL without connect/disonnect the STLink.
2022-04-28 04:31 PM
One program can perform any task after connection to the st-link device thru winusb API.
The problem seems to be that there's no "DLL" for flashing.
2022-04-28 11:48 PM
Ok. This is bad. I thought that there is also a DLL for flashing. How does the RF-Flasher then work?
2022-04-30 06:14 PM
It contains a copy of openocd.exe.
That in its turn uses libusb.dll, that on Windows calls winusb.
Maybe openocd (some version) already has ability to share the debugger connection.
If not - in theory one can "hook" the lowest interface layer, libusb, to share the connection between your app and the openocd. Quite a hack.