STM32H753 UART Baud is 15% low.

[GlennH]

STM32H753 UART Baud is 15% low. I set it to 115200, but it's running at 98400. Is this a misconfigured clock?

[AScha.3]

Obviously you set something wrong ..in clock tree, or uart setting.

see:

 

[GlennH]

AScha.3,

Thank you for the reply. I'm not using CUBE MX on this project. I'm using a vendor-supplied onboard computer that runs FreeRTOS and many vendor-specific tasks. I'm creating just one task in this framework to transfer data from the payload to the OBC for processing and then send the desired information back to the ground station.

Their UARTS all seem to work properly. Here is my setup:

 

oid USART6_RS485_Init()
{
	GPIO_InitTypeDef GPIO_InitStruct = { 0 };

	 /* Peripheral clock enable */
		__HAL_RCC_USART6_CLK_ENABLE();
	 __HAL_RCC_GPIOC_CLK_ENABLE();

	 /**USART1 GPIO Configuration
	 PC6 ------> USART6_TX
	 PC7 ------> USART6_RX
	 PG8 ------> USART6_DE (RTS)
	 */
	 huart6.Instance = USART6;
	 huart6.Init.BaudRate = 115200;
	 huart6.Init.WordLength = UART_WORDLENGTH_8B;
	 huart6.Init.StopBits = UART_STOPBITS_1;
	 huart6.Init.Parity = UART_PARITY_NONE;
	 huart6.Init.Mode = UART_MODE_TX_RX;
	 huart6.Init.HwFlowCtl = UART_HWCONTROL_NONE;
	 huart6.Init.OverSampling = UART_OVERSAMPLING_16;
	 huart6.Init.OneBitSampling = UART_ONE_BIT_SAMPLE_DISABLE;
	 huart6.AdvancedInit.AdvFeatureInit = UART_ADVFEATURE_NO_INIT;

	 if (HAL_UART_Init(&huart6) != HAL_OK)
	 {
	 Error_Handler();
	 }

	 HAL_UART_Receive_IT(&huart6, &rxBuffer[rxIndex], 1);

	 // PIN6 TX from the MCU PIN7 RX to the MCU
	 GPIO_InitStruct.Pin = GPIO_PIN_6 | GPIO_PIN_7;
	 GPIO_InitStruct.Mode = GPIO_MODE_AF_PP;
	 GPIO_InitStruct.Pull = GPIO_NOPULL;
	 GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_VERY_HIGH;
	 GPIO_InitStruct.Alternate = GPIO_AF7_USART6;
	 HAL_GPIO_Init(GPIOC, &GPIO_InitStruct);

	 /*Configure GPIO pin Output Level */
	 HAL_GPIO_WritePin(GPIOG, GPIO_PIN_8, GPIO_PIN_RESET);
	 HAL_GPIO_WritePin(GPIOD, GPIO_PIN_13, GPIO_PIN_RESET);
	 HAL_GPIO_WritePin(GPIOG, GPIO_PIN_13, GPIO_PIN_RESET);

	 // PG8 not PF10

	 GPIO_InitStruct.Pin = GPIO_PIN_8;
	 GPIO_InitStruct.Mode = GPIO_MODE_OUTPUT_PP;
	 GPIO_InitStruct.Pull = GPIO_NOPULL;
	 GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_LOW;
	 HAL_GPIO_Init(GPIOG, &GPIO_InitStruct);

	 /*Configure GPIO pin : RS485_TE_Pin */
	 GPIO_InitStruct.Pin = GPIO_PIN_13;
	 GPIO_InitStruct.Mode = GPIO_MODE_OUTPUT_PP;
	 GPIO_InitStruct.Pull = GPIO_NOPULL;
	 GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_LOW;
	 HAL_GPIO_Init(GPIOD, &GPIO_InitStruct);

	 // PG13 not PF12

	 /*Configure GPIO pin : RS485_nRE_Pin */
	 GPIO_InitStruct.Pin = GPIO_PIN_13;
	 GPIO_InitStruct.Mode = GPIO_MODE_OUTPUT_PP;
	 GPIO_InitStruct.Pull = GPIO_NOPULL;
	 GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_LOW;
	 HAL_GPIO_Init(GPIOG, &GPIO_InitStruct);

	 /* USART1 interrupt Init */
	 HAL_NVIC_SetPriority(USART6_IRQn, 6U, 0);
	 HAL_NVIC_EnableIRQ(USART6_IRQn);

	 // Receive Enable ACTIVE
	 USART6_RS485ReceptionEnable();

	 // Termination Enable ACTIVE
	 // MacCfg_vSetBusTerminationState(eMAC_Interface_Primary, MacCfg_bGetBusTerminationState(eMAC_Interface_Primary, true), true);

	 // Start with a disabled communication driver...
	 USART6_RS485DriverDisable();
}

 

 

 

[Tesla DeLorean]

Speed is going to be the function of the synchronous clocks involved. The math on the rates is dependent on the validity of the data furnished, ie garbage in, garbage out

HSI would be a known quantity, within a few percent, however HSE is unknown and unmeasured by the MCU

[TDK]

If the baud rate is not what you want, it is not configured correctly.

Some background into your hardware and how the clock rate is configured and how you are measuring that clock rate would be appropriate. Without that, one can only guess at the issue.

• Incorrect system clock setting
• Wrong BRR value
• Misinterpretation of results

[GlennH]

TDK,

Thank you for the response. Please see my answer to AScha.3 above.

[Tesla DeLorean]

Sounds like something is very broken on your system, that you don't describe at all.

Measure HSE / PLL via MCO (PA8)

Check HSE_VALUE define (stm32h7xx_hal_conf.h) and its relationship with reality.

[GlennH]

Tesla DeLorean,

Thank you for the reply.

I will check the HSE / PLL at my first opportunity.

The HSE_VALUE is (uint32_t) 25000000

 

[Tesla DeLorean]

15% might suggest a reality of closer too 21.25 or 28.75 MHz

An APB of a few 100 MHz should have about zero difficulty hitting 115200 baud, as the bus clock drops the ability to resolve diminishes, but still to a few percent worst case.

Sending 0x55 'U' at 8N1 continuously should result in a square wave half the baud frequency.

[BarryWhit]

---

@GlennH wrote:

STM32H753 UART Baud is 15% low. I set it to 115200, but it's running at 98400. Is this a misconfigured clock?

---

What are you actually measuring and how? Please describe the measurement process that yielded 98400 as the result.

[GlennH]

Hi Barry,

Thanks for the reply.

I measured the time for 1 bit on an oscilloscope then 1/time. Then I dialed it in on Realterm until I received reliable characters.

[Andrei Chichak]

Throw together a basic model in CubeMX with the crystal frequency that you are using and the UART baud that you want, generate code and compare it to your code. 

If you don't want to use CubeMX code, don't use it, just use their calculations.

[GlennH]

Hi Andrei,

Thanks for the reply.

That is an awesome idea! 

 

[BarryWhit]

How can the wrong value for an integer divisor prescaler cause a 15% error in baud rate?!

If DIV=1 gives you the expected baud rate, and this really was the cause behind your issue, that would mean that the integer-valued prescaler was previously set to DIV=1.15, which is impossible.

[Tesla DeLorean]

Exactly, I think we're getting a very selective view of the facts/details, as on it's own that makes no rational sense.

Perhaps it breaks the math for the BRR computation, but none of the register values has been shared or contextualized. Details of the memory the variables reside in, or the structure content as passed to the initialization routine.