HAL UART RX Pulls Down

[bsch1]

Hello,

I am currently using a STM32F429ZI-DISC1 Discovery Board.

I tried to get a UART tranmission going through CubeMX/HAL Drivers.

Transmitting data works perfectly fine but when trying to receive any data I don't have any chance. So I was looking over the signals with my Logic Analyzer and I realized that the initalized RX is pulling down the "partners" TX. In the picture you can see the moment I power the STM, TX goes high but RX pulls down the external TX.

This is my referring init:

static void MX_UART4_Init(void)
{
 
  huart4.Instance = UART4;
  huart4.Init.BaudRate = 115200;
  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;
  if (HAL_UART_Init(&huart4) != HAL_OK)
  {
    _Error_Handler(__FILE__, __LINE__);
  }
 
}

And this is the code I tried to receive data:

while(inpData != 0x02){
		HAL_UART_Receive(&huart4,&inpData,sizeof(uint8_t),10);
	}
  	HAL_UART_Transmit(&huart4, &start, sizeof(uint8_t), 7);
  	/*HAL_UART_Transmit(&huart7, &start, sizeof(uint8_t), 1);
  	HAL_UART_Transmit(&huart8, &start, sizeof(uint8_t), 1);*/
  	//HAL_Delay(50);
  	for(int i = 0;i < 1024;i++){
  		HAL_UART_Transmit(&huart4, &Data[i], sizeof(uint8_t), 7);
  		//HAL_Delay(1);
  	}

So why does the RX pulls down the data line?

Thanks for your help!

[Tesla DeLorean]

>>So why does the RX pulls down the data line?

Check the MSP's GPIO Initialization code. Could just be letting it float.

Not sure how it would be low, presumably the other end would be driving it high in a normal static/inactive state. And thus a "pull-down" isn't going to over-come a PP-driver at the other end. The STM32 would need to be actively clamping it to ground, which seems a bit improbable unless there is some other hardware/design issue.

[Tesla DeLorean]

Not sure what pin this is, and I'm not going to dig, but the F429I-DISC has most pins committed to other functions/parts on the board. Check User Manual for conflicting uses.

[bsch1]

So I was not sure about the right initalization as well, so I also tried to initalize the UART throught GPIO on PA0(TX) and PA1(RX) but it was no use either.

static void MX_GPIO_Init(void)
{
 
  GPIO_InitTypeDef GPIO_InitStruct;
 
  /* GPIO Ports Clock Enable */
  __HAL_RCC_GPIOF_CLK_ENABLE();
  __HAL_RCC_GPIOA_CLK_ENABLE();
  __HAL_RCC_GPIOD_CLK_ENABLE();
  __HAL_RCC_GPIOC_CLK_ENABLE();
  __HAL_RCC_GPIOE_CLK_ENABLE();
/* PA0 */
  GPIO_InitStruct.Pin = GPIO_PIN_0|GPIO_PIN_1;
  GPIO_InitStruct.Mode = GPIO_MODE_AF_PP;
  GPIO_InitStruct.Pull = GPIO_NOPULL;
  GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_VERY_HIGH;
  GPIO_InitStruct.Alternate = GPIO_AF8_UART4;
    HAL_GPIO_Init(GPIOA, &GPIO_InitStruct);
  /*Configure GPIO pin : PD12 */
  GPIO_InitStruct.Pin = GPIO_PIN_12;
  GPIO_InitStruct.Mode = GPIO_MODE_INPUT;
  GPIO_InitStruct.Pull = GPIO_NOPULL;
  HAL_GPIO_Init(GPIOD, &GPIO_InitStruct);
 
}

[bsch1]

It seems like there is a general issure with the input Pins..

So when I try to read PD14 on a high flag instead of using the UART the same thing happens, it just gets pulled down. In the logic analyzer you can see a low Voltage difference of 0.1 Volts when the Pin should be set on a high-state but not the usual 2.9-3.3V it is set to when not connected to the STM. I have connected both GNDs.

This is my PD14 Code + Init:

  /*Configure GPIO pin : PD12 */
  GPIO_InitStruct.Pin = GPIO_PIN_12 | GPIO_PIN_14;
  GPIO_InitStruct.Mode = GPIO_MODE_INPUT;
  GPIO_InitStruct.Pull = GPIO_NOPULL;
  HAL_GPIO_Init(GPIOD, &GPIO_InitStruct);
 
 

while(HAL_GPIO_ReadPin(GPIOD, GPIO_PIN_14) == GPIO_PIN_RESET){
		/* wait  */
}

[Tesla DeLorean]

Check conflicting pin usage. Check the schematic

https://www.st.com/content/ccc/resource/technical/document/user_manual/6b/25/05/23/a9/45/4d/6a/DM00093903.pdf/files/DM00093903.pdf/jcr:content/translations/en.DM00093903.pdf

[bsch1]

I don't think it has something to do with conflicting PIN usage. I also tried it with PD7 which has no alternate function but it is just the same as with PD14.

[turboscrew]

If, at the other end, the RX-line is floating, the same happens with any UART.

Check your connections. If configured right, RX-pin is not driven at all. The drivers should be disconnected from the RX-pin.

 For that chip, UART4-pins are A0 and A1 or PC10 and PC11.

 According to the link, PA0 is also connected to a push button, and PA1 to L3GD20 INT1.

Also, you might try without configuring the RX pin to alternate push-pull, but just input. I think it should work both ways.

[bsch1]

So what I found out is: When not initalizing the PINs I can read them out just fine for like 5 minutes, then they completly reset. But as soon as I try to initalize the PIN with HAL-Drivers it does not work properly, so might there be a mistake in the HAL_GPIO lib?