cancel
Showing results for 
Search instead for 
Did you mean: 

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
Associate II

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 ?

7 REPLIES 7
Uwe Bonnes
Principal III

Did you have a look with a scope?

+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

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:

0690X00000AsIGAQA3.png

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

Waiting for your valuable input.

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
Associate II

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

0690X00000AsKbZQAV.png

and also like below:

0690X00000AsKbeQAF.png

Please check

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

:thumbs_up: