cancel
Showing results for 
Search instead for 
Did you mean: 

STM32H735 UART2 HAL_UART_Receive_IT and HAL_UART_Receive puts a first byte in the buffer that is not there.

MStei.4
Associate III

I am a bit frustrated with the USART2, which is connected to the UART9 TX9-RX2 and TX2-RX9. So with sending from TX9 to RX2 everything is fine but the other way around there is a first byte = 254d inside the receive buffer. huart2 and huart9 are initialized totally equal asynchronous with the default CubeIDE configuration. 

huart9.Instance = UART9;
  huart9.Init.BaudRate = 115200;
  huart9.Init.WordLength = UART_WORDLENGTH_8B;
  huart9.Init.StopBits = UART_STOPBITS_1;
  huart9.Init.Parity = UART_PARITY_NONE;
  huart9.Init.Mode = UART_MODE_TX_RX;
  huart9.Init.HwFlowCtl = UART_HWCONTROL_NONE;
  huart9.Init.OverSampling = UART_OVERSAMPLING_16;
  huart9.Init.OneBitSampling = UART_ONE_BIT_SAMPLE_DISABLE;
  huart9.Init.ClockPrescaler = UART_PRESCALER_DIV1;
  huart9.AdvancedInit.AdvFeatureInit = UART_ADVFEATURE_TXINVERT_INIT;

after Init I do this in the main() routine:

uint8_t cnt = 0u;
uint8_t strU9Sent[6u];
uint8_t strU2Received[6u];
 
sprintf((char *)strU9Sent, "hello", cnt);
HAL_UART_Receive_IT(&huart2, strU2Received, sizeof(strU2Received));
HAL_UART_Transmit(&huart9 , strU9Sent, sizeof(strU9Sent), 100u);

After executing HAL_UART_Receive_IT() one can set a breakpoint at line 6 (code above), there is immediately a character in the strU2Received. Also the blocking HAL_UART_Receive() creates that issue. On the oscilloscope there is no character or something visible.

Why that?

This is reproducible with generated code from CubeIDE 10.0.1.

1 ACCEPTED SOLUTION

Accepted Solutions

> Look at the RX line in the moment of enabling the UART.

+1

You possibly won't see any noise but a 0-to-1 transition *after* the Rx was enabled, but that's it. The line needs to be high before you enable UART_Rx. Use a pullup, internal or external, before you enable UART_Rx. In the weird Cube/HAL world GPIOs for UART are set probably in some MSP something something, but maybe you just use some clicking, I don't use Cube. Given capacitive load, internal pullup may result in not fast enough transition.

JW

View solution in original post

6 REPLIES 6
Pavel A.
Evangelist III

After enabling a UART it can mistake some noise on the RX line for start bit.

The protocol should be resistant to this and ignore the erroneous 1st byte.

If this occurs more than once, check for noise.

MStei.4
Associate III

Hello Pavel, thanks for the answer. Attached some screen shots from the oscilloscope where I use a larger buffer and send the data roundrip from UART2 to UART9 and back from UART9 to UART2. There are no noises as I can see.

0693W00000SwDQ0QAN.png0693W00000SwDQ5QAN.pngThis is the receive buffer now with the first byte = 248d.

0693W00000SwDQFQA3.pngThis byte is only received with USART2 and not seen on HW. Could this also be a problem in the HAL?

You show two TX lines (UART2 and 9?). Look at the RX line in the moment of enabling the UART.

> Look at the RX line in the moment of enabling the UART.

+1

You possibly won't see any noise but a 0-to-1 transition *after* the Rx was enabled, but that's it. The line needs to be high before you enable UART_Rx. Use a pullup, internal or external, before you enable UART_Rx. In the weird Cube/HAL world GPIOs for UART are set probably in some MSP something something, but maybe you just use some clicking, I don't use Cube. Given capacitive load, internal pullup may result in not fast enough transition.

JW

MStei.4
Associate III

0693W00000SwJrgQAF.pngThe lines are connected as shown in the picture above. The HAL_UART_Receive_IT function is called long after initialization. Until receive, the signal level does not change at both pins. I will try to initialize with pulled up RX on USART2.

Okay, thanks that was it, I've setup the pull-up for RX

void HAL_UART_MspInit(UART_HandleTypeDef *huart)
... 
GPIO_InitStruct.Pull = GPIO_PULLUP;

and the ghost byte is gone. I don't use cube but of course ST HAL. I am using the same code for different STM32 uC, so without HAL a BSP would be a lot of effort.