STM32F429ZI UART5 data is received on terminal only for Baud rates 9600 & 4800 for higher baud rates we get garbage data. What can be the issue ?

[Rahul1]

System Clock is PLL_HSE

HSE connected is 12MHz

HSE_VALUE is set 12000000 & SystemCoreClock = 180000000 in system_stm32f4xx.c

HCLK = 180MHz

PCLK1 = 45MHz

PLLM = 12;

PLLN = 360;

PLLP = RCC_PLLP_DIV2;

PLLQ = 4;

Clocks are configured as expected, cross checked RCC registers through debugger.

Baud rate register is also verified and the value matches with the calculations.

What can be the issue ?

[Uwe Bonnes]

Did you have a look with a scope?

[waclawek.jan]

+1

also, what exactly are "garbage data" - is it reproducible, can you show pairs of transmitted/received characters?

JW

PS Please change your username to a normal nick

[Rahul1]

Here's my code:

int main(void)
{
	float tmp_flt = 1.543;
	uint32_t apb1Clk;
	char tmp_ch = 'A';
	char tmp_ch1 = 'B';
 /* Reset of all peripherals, Initializes the Flash interface and the Systick. */
 HAL_Init();
 
 /* Configure the system clock */
 SystemClock_Config();
 SystemCoreClockUpdate();
 apb1Clk = HAL_RCC_GetPCLK1Freq();
 
 /* Initialize all configured peripherals */
 MX_GPIO_Init();
 MX_RTC_Init();
 MX_SPI1_Init();
 MX_UART5_Init();
 /* USER CODE BEGIN 2 */
 HAL_Delay(500);
 
 while (1)
 {
	 HAL_Delay(500);
	 printf("printf float: \n\r");
	 printf("data on line 2\n\r");
	 printf("data on line 3\n\r");
	 HAL_Delay(500);
 }
}

printf is used by using following function:

#ifdef __GNUC__
#define PUTCHAR_PROTOTYPE int __io_putchar(int ch)
#else
 #define PUTCHAR_PROTOTYPE int fputc(int ch, FILE *f)
#endif /* __GNUC__ */
PUTCHAR_PROTOTYPE
{
 HAL_UART_Transmit(&huart5, (uint8_t *)&ch, 1, 0xFFFFFFFF);
 return ch;
}

Terminal view is as follows:

Kindly go through it, anything else you need just tell me.

Waiting for your valuable input.

[waclawek.jan]

Very interesting - almost completely repeatable, and much of the characters gets through unaffected, that's remarkable.

I'd say, there's some slight baudrate mismatch involved. I know you are using HSE/crystal and the baudrate is not that high compared to system clock, so the mismatch should be relatively low; but what's on the receiving side? Is it some USB-to-UART converter? Can't that be mismatched? Can you try a different one (different make, different chip)? Or, even better, can you locate a PC with an onboard UART? Can you try to transmit on it and measure precisely enough the bit duration (you need to get to some 1% resolution at least)? Is there some level conversion involved (RS232)?

JW

[Rahul1]

You are right USB to RS232 converter was the issue.

Changed it with FTDI FT232RL.

Now issue is little different as you can see below

and also like below:

Please check

[waclawek.jan]

I honestly don't know. At this stage, you might really need an oscilloscope or maybe even better a logic analyzer and look at the actual Tx signal.

JW

[Rahul1]

:thumbs_up: