0
\$\begingroup\$

I have simple code which writes to the USART on a Nucleo board that is connected to ST-Link, and appears on my workstation via VCP over USB.

I'm trying now to port it to a STM32H735G-DK Discovery but see no output on my VCP on my workstation.

According to the board manual

The serial interface USART3 (PD8/PD9) that supports the bootloader is directly available as a Virtual COM port of the PC connected to the CN15 STLINK-V3E USB connector. The VCP configuration is the following: • 115200 bps • 8-bit data • No parity • One-stop bit • No flow control

So I moved my RCC and GPIO code to use USART3, PD8, PD9 (instead of the values on the Nucleo board):

  #define MY_USART USART3
...
  rcc_periph_clock_enable(RCC_USART3);
  // and wires USART2 to PD8 (TX) and PD9 (RX)
  rcc_periph_clock_enable(RCC_GPIOD);
  // Set both pins to AF7
  gpio_mode_setup(GPIOD, GPIO_MODE_AF, GPIO_PUPD_NONE, GPIO8 | GPIO9);
  gpio_set_af(GPIOA, GPIO_AF7, GPIO8 | GPIO9);
...
  usart_set_baudrate(MY_USART, 115200); // The other defaults are correct: 8N1, etc.
  usart_set_flow_control(MY_USART, USART_FLOWCONTROL_NONE);
  usart_set_mode(MY_USART, USART_MODE_TX_RX);
  usart_enable(MY_USART);
  usart_send_blocking(MY_USART, b);

but no output ("0 bytes received").

What further perplexes me is that this example by ST themselves, for the very same board uses USART1 (not USART3).

I can't find any explicit docs stating the correct Alternate Function for the pins, but I believe it is AF7.

My question is: How do I debug this? I've verified via gdb that my code is being called, including usart_send_blocking(MY_USART, b). I've verified my VCP works via the Nucleo board. The most likely culprit would be incorrectly setting up RCC, GPIO pins, or simply using the wrong pins or UART - but how do I debug that? There's no error or exception in that case, just a no-op.

\$\endgroup\$

1 Answer 1

2
\$\begingroup\$

You might want to set AF7 to PORTD pins 8 and 9 instead of PORTA pins 8 and 9.

\$\endgroup\$
2
  • \$\begingroup\$ Ouch! Not sure how I missed that. Now I get a single 0xff byte, but no more. Working to debug... \$\endgroup\$ Sep 27, 2023 at 19:22
  • \$\begingroup\$ Well, the value of b is unknown to us. So is the baud rate because even if you set some baud rate, we don't know at what clock speed the baud rate setting code expects the UART to be clocked, and if the UART is really clocked at that rate, or if you are simply using clocks that are so imprecise that they can't be used for UART. So it's unclear what your "simple" mystery code and functions really do. At least you get output so this question is solved and you might want to start a new question for other problems. \$\endgroup\$
    – Justme
    Sep 27, 2023 at 19:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.