[STM32F411RE] USART2 data always goes to ST-LINK VCP instead of PA2/PA3 pins

[JaunAlejo]

Problem description

Hi everyone,

I’m working with a NUCLEO-F411RE board and I need to use USART2 (PA2=TX, PA3=RX) to communicate with a LoRa module (Reyax RYLR998).

The issue is: even though I configure USART2 in CubeMX, all data I send ends up on the COM9 (ST-LINK VCP) of my PC (USB micro connector), not on the physical pins PA2/PA3.

What I want:

• Data should go out via PA2/PA3 → LoRa module.

• But instead it always goes to the PC via COM9.

---

What I already checked

1. CubeMX configuration

   • USART2 enabled in Asynchronous mode.

   • PA2 assigned to USART2_TX, PA3 assigned to USART2_RX.

   • Baudrate = 115200, 8N1, no flow control.

   • SYS/Debug set to Serial Wire (not Trace Asynchronous SW).

2. printf redirection

   • No active redirection to ITM/SWV.

   • When using printf, I have _write function pointing to huart2:

      

     int _write(int file, char *ptr, int len) { HAL_UART_Transmit(&huart2, (uint8_t*)ptr, len, HAL_MAX_DELAY); return len; }

3. SWV disabled

   • In CubeMX: Debug = Serial Wire only.

   • Not using ITM or ITM_SendChar.

4. Direct test in code
   Configured PA2/PA3 manually as alternate function AF7 and tested:

    

   HAL_Delay(2000); char test[] = "UART2_FISICO_TEST\r\n"; HAL_UART_Transmit(&huart2, (uint8_t*)test, strlen(test), 1000);

   → The string still shows up on COM9, not on the LoRa module.

5. Registers checked in debugger

   • GPIOA->MODER shows AF mode for PA2/PA3.

   • GPIOA->AFR[0] = 7 for those pins.

   • USART2->CR1 is enabled.

---

My suspicions

• Maybe printf redirection is still enabled towards ST-LINK VCP somehow.

• On NUCLEO boards, solder bridges SB62/SB63 connect PA2/PA3 to the ST-LINK VCP, so maybe that’s why the PC always sees the data.

• I’m not sure if it’s even possible to receive from an external sensor on USART2_RX (PA3) while those solder bridges remain connected, or if that would cause line conflicts with ST-LINK RX.

---

Question

How can I force USART2 to use only the physical PA2/PA3 pins and not be redirected to COM9 (ST-LINK VCP)?

• Is cutting SB62/SB63 really the only option, or is there a CubeMX/firmware configuration I’m missing?

• If I connect a sensor to USART2_RX (PA3), will it conflict with ST-LINK RX and cause collisions?

•  Any advice on how to free PA2/PA3 for my LoRa module (ideally without losing COM9 debugging) would be very helpful.

Thanks in advance!

[STTwo-32]

Hello @JaunAlejo and welcome to the ST Community.

The USART2 interface available on PA2 and PA3 of the STM32 microcontroller can be connected to ST-LINK MCU, ST morpho connector, or ARDUINO® connector. The choice can be changed by setting the related solder bridges. By default, the USART2 communication between the target STM32 and ST-LINK MCU is enabled, to support virtual COM port (SB13 and SB14 ON, SB62 and SB63 OFF). If the communication between the target STM32 PA2 (D1) or PA3 (DO) and shield or extension board is required, SB62 and SB63 must be ON, while SB13 and SB14 must be OFF. In such a case, it is possible to connect another USART to the ST-LINK MCU using flying wires between the ST morpho connector and CN3.

So, as a conclusion, to use the USART2 on physical PA2/PA3 pins, you have to solder the SB62 and SB63 and take off the SB13 and SB14.

Best Regards.

STTwo-32.

[Andrew Neil]

This is not a "problem" - this is clearly documented in the User Manual for the board:

https://www.st.com/resource/en/user_manual/um1724-stm32-nucleo64-boards-mb1136-stmicroelectronics.pdf#page=91

via: https://www.st.com/en/evaluation-tools/nucleo-f411re.html#documentation

You can also see it in the schematics:

https://www.st.com/resource/en/schematic_pack/mb1136-default-c04_schematic.pdf

via: https://www.st.com/en/evaluation-tools/nucleo-f411re.html#cad-resources

 

---

@JaunAlejo wrote:

all data I send ends up on the COM9 (ST-LINK VCP) of my PC (USB micro connector), not on the physical pins PA2/PA3.

---

That's not true: the data does appear on the physical pins PA2/PA3, and those pins are then connected to the ST-Link's VCP:

 

 

@STTwo-32 But it does seem unhelpful that the nets have different names on the ST-LINK and MCU sheets - which rather obscures the connection.

Everything else that's connected between sheets has the same name on all sheets.