UART Communication Using UART to USB cable.

[noel]

I'm trying to get a simple UART hello world program to work. It just transmits a buffer once per second. I've enabled UART2, enabled the interrupt, and configured the baud rate, parity, and word length. But when I open minicom I don't see anything. I know the loop is running because I'm toggling the LED on every transmit. I've also tried implementing the receive callback and sending messages to the stm32 with a Python script (this was actually the first thing I tried, but I decided to simplify things to troubleshoot.)

I'm using this cable

I've got the white wire (tx) connected to USART2_TX (PA2) and the green wire (rx) connected to USART_RX (PA3) and the black write (gnd) connected to GND.

Does anybody have any tips on troubleshooting this?

[BarryWhit]

For UART connections, TX/RX pins always indicate data direction relative to that device.

So TX of the STM32 is where it sends data out.

and TX of the UART cable is where it sends data out.

 

Therefore, you always connect the TX of one to the RX of the other and vice-versa.

[noel]

Oh. Yeah that was silly. I swapped the pins and still no joy.

[BarryWhit]

There's a slim chance something was damaged by connecting TX to TX, but I've made this mistake plenty of times and never had that happen.

 

Did you adjust baud rate in minicom to match?

Did you do a loopback test of the cable? connect RX and TX of cable and check that minicom echos back what you type. I'm assuming you do not have local echo turned on.

 

If neither helps, post your main() code (please use the code block button on the toolbar above, which looks like </>, or the code will look terrible).

[noel]

I'm using the command `minicom -D /dev/ttyUSB0 -b 9600` for minicom which is the same settings I applied to UART2. So the baud rate should be good.

I tried the loop back test with my cable and that worked.

Here is the main code:

int main(void)
{
 uint8_t tx_buffer[27] = "Hello, World!\n\r";

 HAL_Init();
 SystemClock_Config();
 MX_GPIO_Init();
 MX_USART2_UART_Init();

 HAL_UART_Receive_IT(&huart2, UART2_rxBuffer, sizeof(UART2_rxBuffer));

 while (1)
 {
	 HAL_UART_Transmit(&huart2, tx_buffer, 27, 10);
	 HAL_GPIO_TogglePin(GPIOA, GPIO_PIN_5);
	 HAL_Delay(1000);

 }
}

[BarryWhit]

- Check the TX pin on the STM32. With a scope if you have one, but even with a multimeter in DCV mode, you should be able to see the reading flicker periodically. 

- Did you connect GND between your STM32 and USB Serial cable?

- Generally, but especially if you're having issues, you should not ignore the return value from HAL_UART_Transmit. It might be reporting an error that you're ignoring.

 

General Note:

Your code sends the entire contents of the 27 byte buffer, but only a portion of it is your actual string, the rest will be either zero or random garbage. When sending strings over UART,  use either `strlen()` or const fixed-length strings (whose size is known at compile-time)

 

 

HAL_UART_Transmit(&huart2, tx_buffer, strlen(tx_buffer), 10);
// or
const uint8_t tx_buffer[] = "Hello world\r\n"; // auto-size buffer to fit string (+terminating null)
HAL_UART_Transmit(&huart2, tx_buffer, sizeof(tx_buffer)-1, 10);

 

 

Additionally, it's customary to use CRLF ('\r\n') and not LFCR ('\n\r'). There must be a good reason for that, though now that I'm pointing this out to you I realize I don't know what it is - other than convention.

Update:

da internatz can haz answrz

On teletypes, CRLF amortizes the delay of a CR operation (moving the head back across the width of a page) over two bytes, while LFCR doesn't. ...and here we are with TFLOPS in our pockets still blindly obeying history.

[Andrew Neil]

Before going to interrupts, have you tried just a plain blocking send?

As @BarryWhit said, use an oscilloscope or logic analyser to check what's happening on the pin.

 

---

@noel wrote:

I'm using the command `minicom -D /dev/ttyUSB0 -b 9600` for minicom which is the same settings I applied to UART2. So the baud rate should be good.

---

If your target clock is inaccurate and/or misconfigured, the baud rate could be wrong ...