How do I maximize baudrate via USART with STM32L4P?

[crackl1ng]

Hi STM32-Community,

I'm currently trying to maximize my dataouput. I've about 150 KB/s data, which are sent out via RS485 and connected with a RS485 to USB to my PC. The USART Clock is at 64 MHz, though 80 MHz viable aswell, which means I should be able to send data with 4 to 5 MBaud. However, the data is corrupted beyond a baudrate 256000 and I do not understand why. I also have oversampling at 16. Here is my USART init:

void MX_UART4_Init(void)
{
 
 /* USER CODE BEGIN UART4_Init 0 */
 
 /* USER CODE END UART4_Init 0 */
 
 /* USER CODE BEGIN UART4_Init 1 */
 
 /* USER CODE END UART4_Init 1 */
 huart4.Instance = UART4;
 huart4.Init.BaudRate = 256000;
 huart4.Init.WordLength = UART_WORDLENGTH_8B;
 huart4.Init.StopBits = UART_STOPBITS_1;
 huart4.Init.Parity = UART_PARITY_NONE;
 huart4.Init.Mode = UART_MODE_TX_RX;
 huart4.Init.HwFlowCtl = UART_HWCONTROL_NONE;
 huart4.Init.OverSampling = UART_OVERSAMPLING_16;
 huart4.Init.OneBitSampling = UART_ONE_BIT_SAMPLE_DISABLE;
 huart4.Init.ClockPrescaler = UART_PRESCALER_DIV1;
 huart4.AdvancedInit.AdvFeatureInit = UART_ADVFEATURE_NO_INIT;
 if (HAL_UART_Init(&huart4) != HAL_OK)
 {
 Error_Handler();
 }
 if (HAL_UARTEx_SetTxFifoThreshold(&huart4, UART_TXFIFO_THRESHOLD_1_8) != HAL_OK)
 {
 Error_Handler();
 }
 if (HAL_UARTEx_SetRxFifoThreshold(&huart4, UART_RXFIFO_THRESHOLD_1_8) != HAL_OK)
 {
 Error_Handler();
 }
 if (HAL_UARTEx_DisableFifoMode(&huart4) != HAL_OK)
 {
 Error_Handler();
 }
 /* USER CODE BEGIN UART4_Init 2 */
 
 /* USER CODE END UART4_Init 2 */
 
}

I'm trying to read the data with Matlab/Terminal, but the data keeps being received wrong.

I'm thankful for every advice.

Kind regargds

[Bubbles]

Hi @crackl1ng​ ,

you should focus on the GPIO settings. Make sure the GPIO is set to operate on the maximum speed. Then it also depends on what load is connected to the GPIO. High load may limit the switching speed. Check the datasheet to see the parameters.

1MBaud should normally be no problem, you can use scope to see the slope shape on the GPIO pin and then after the external 485 driver IO. You'll see where the problem is.

BR,

J.

[TDK]

Not all receivers support high clock rates. The STM32 can send 5MBaud, but that doesn't mean the receiver will work with that. For example, the very popular FT230X chip only supports up to 3 MBaud.

Use a scope to verify the signal being sent by the STM32. If it's correct, the problem is on the receiver side.

[crackl1ng]

Thank you both for your replies, I will consider what you advised and come back after testing. Thank you very much!

[crackl1ng]

Hello STM32-Community,

I've changed my GPIO speed to "Very Fast", the highest speed available. 1 MBaud seemed to work fine, while everything beyond, e.g. 1.5MBaud did not work properly:

Any ideas how to resolve this?

Kind regards

[Bubbles]

Hi @crackl1ng​ ,

the GPIO speed setting sets the power of the GPIO driver. Basically the amount of energy necessary to make the transition from one level to the other level as fast and precise as possible. But the GPIO driver has it's limits. You need to check the electrical properties of the rest of the com line, capacity, inductance, resistance and make sure the load is al low as possible.

What's the distance from STM32 to the RS485 bus driver? Is the bus driver up to the task?

BR,

J.

[TDK]

What chip are you interfacing with on the PC side? How do you know it supports rates over 1Mbaud?

[TDK]

That signal plot is not okay. The start bit is much too short on most or all of the bytes. It's especially apparent when the LSB is 1. It would be nice to see the time scale for these. Is this from 1.5 MBaud or 1MBaud? What is the code that generates this signal?

 

A quick glance suggests the CH340 only works up to 2MBaud per the datasheet. Doesn't explain the issues at 1.5, of course.

https://cdn.sparkfun.com/datasheets/Dev/Arduino/Other/CH340DS1.PDF

[crackl1ng]

I checked the specifications stated ont he website where I purchased them and it stated a 6 MBaud upper limit, though I suppose the data sheet is more correct.

The code I wrote for that is pretty simple. I do not send any data from a sensor yet, since I cannot approve the correctness of the signal therefore I have this simple loop:

 for (int i = 0; i< 5; i++)
 {
	 buf_send[i] = i;
 }
 
 while(1)
 {
	HAL_GPIO_WritePin(DE_485_GPIO_Port, DE_485_Pin, GPIO_PIN_SET);
	HAL_UART_Transmit(&huart4, buf_send, 5, 0x1000);
	HAL_GPIO_WritePin(DE_485_GPIO_Port, DE_485_Pin, GPIO_PIN_RESET);
	//HAL_Delay(500);
 }

The image is from the 1.5 MBaud analyzing.

[Andrew Neil]

Have you looked at the signals on an oscilloscope?

@TDK​ "The start bit is much too short on most or all of the bytes."

That could be the result of too-slow edges - so the LA's 0/1 threshold doesn't happen where it should ...

Use a scope to look at the signals at the receiver inputs.

[TDK]

Other edges are fine, so I don't see how that could be the case. They would all be delayed the same amount. It is consistently the start bit that is off.

[Andrew Neil]

would still be worth looking on a scope - to see what's actually happening in the analogue domain ...