STLINK-V3MODS UART API

[debugging]

Hello,

The documentation and flyers of the STLINK-V3MODS specify that the product includes an USB to UART bridge. My custom board with the V3MODS works for JTAG/SWD, I2C and Virtual UART. However, the documentation and sample code does not contain an API for the UART. Is such feature planned for the future  ?

In the mean time the manual states that CAN has not been tested with real CAN bus. has this already been done ?

[AM · Accepted solution]

Hello,

You can refer to the STLINK-V3MODS reference manual and TN1235 Overview of ST-LINK derivatives to find how to activate the Bridge UART signals. The Bridge UART functionality is only provided as a second Virtual COM port (not as a dedicated UART API).

"Bridge UART
UART signals with hardware flow control (CTS/RTS) are available on MB1467 CN2 pins 1,2, 3, and 11. They need dedicated firmware to be programmed on the main module before being used. Without this firmware, the Virtual COM port function must be used instead (no hardware flow control)."

TN1235:

"1.2.2 USB interface selection,  Figure 2. STLINK-V3 firmware selection for a second Virtual COM port"

For CAN BRIDGE API, yes: in the meantime, it has been tested with a STLINK-V3SET + an internal validation board  with a CAN transceiver connected to a STM32 evaluation board target having a CAN transceiver.

Best regards

[Andrew Neil]

What do you mean by, "API for the UART" ?

At the microcontroller end, it's just a UART - you send async serial data to it, and receive async serial data from it

At the Host end, it's a standard USB CDC/ACM, which the Host OS presents as a virtual COM port (a virtual tty on Linux)

[AM]

Hello Andrew,

It means that the STLINK-V3SET/MODS bridge UART signals can be used by the USB host using the second USB Virtual COM port interface (as you said) but not using the USB Bridge interface (used for Bridge I2C, SPI, ... with STLINK-V3-BRIDGE API, https://www.st.com/en/development-tools/stlink-v3-bridge.html ). I hope this clarifies.

Best regards

[debugging]

Thanks, but the documentation made it look like it was accessed via the bridge API. I assumed that was the case while still using the storage feature.

I downloaded the STlink upgrade package, and ran the udev rules.

I had to change form java-8 to jdk-21 openjdk version then run

java -jar STLinkUpgrade.jar

Then found the "type" option and changed it, and it now there are now two Virtual UARTS :)

P.S what is the use of the storage media ? For what purpose it can be used?

[AM]

Hello

I am happy you solved the java issue and found the second VCP.

Mass storage feature was implemented mainly for ARM-MBED Drag and Drop programming support with the Nucleo/Discovery boards embedding an STLINK. However, it can now be considered outdated, and it is recommended to use STM32CubeProgrammer software to program your target. (you may find more information and an issue example in this post https://community.st.com/t5/stm32-mcus-boards-and-hardware/st-link-stlink-mass-storage-drag-and-drop-programming-issues/m-p/586348 )

Best regards

[debugging]

Thanks, Is the (2nd) UART programmed for RTC/RTS flow control and are thise pins default pull down ? I assume there isn't an API to change the flow control method, right ?

[AM]

Hello,

Yes, a pull down on CTS (input for STLINK). It is detailed more in the STLINK-V3SET user manual:

"The hardware flow control might be activated by physically connecting UART_RTS and/or UART_CTS signals to the target. If not connected, the second Virtual COM port works without hardware flow control. Note that the hardware flow control activation/deactivation cannot be configured by software from the host side on a Virtual COM port; consequently configuring a parameter related to that on the host application does not affect the system behavior."

Best regards

[debugging]

Thanks, interestingly, I don't see any data coming out of  the 2nd UART keeping the lines floating. I'll debug this further if perhaps it needs a PU on TX/RX like the 1st UART.