Skip to main content
Benjamin Brammer
Senior II
December 12, 2018
Question

UART5 on STM32F429IDISCOVERY not working properly in interrupt mode

  • December 12, 2018
  • 3 replies
  • 991 views

Hey guys,

I am using UART5 of the board to communicate with a display from 4DSystems. I formerly used the blocking mode with HAL_UART_Transmit(..) and HAL_UARRT_Receive(..) which worked absolutelex fine. Since my orject is getting quite complex and ADC, DMA and I2C is all working in parallel, I sometimes mis message from or to the display. I think this is because I use the blocking mode which can get interrupted by DMA handling and if the situation is right this might occur directly in a bit shifting process to the UART peripheral. So to block this I want to use the HAL_UART_Transmit_IT(..) and Receive functions, so that the dma cannot interrupt an ongoing UART receive or transmit process.

Sadly my routine is not working and I honestly don't know why.

I write a command to the display with the following function:

void WriteObject_command(uint8_t objID, uint8_t objIndex, uint16_t data) //todo: tx/rx implement
{
	uint8_t command[6] = {0};
 
	command[0] = 0x01;
	command[1] = objID;
	command[2] = objIndex;
	command[3] = (data >> 8);
	command[4] = data;
	command[5] = command[0]^command[1]^command[2]^command[3]^command[4];
 
	//transmit / receive//
	 if(HAL_UART_Transmit_IT(&huart5, (uint8_t *)&command[0], 6)!= HAL_OK)
	 {
	 Error_Handler();
	 }
	 while(!UartReadyTX);
	 while(!UartReadyRX);
}

II need the blocking since I cannot issue another transmit or receive if a former command isn't processed already, thats why I wait for the two flags to be set in HAL_UART_TxCpltCallback(UART_HandleTypeDef *huart) and in HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart).

The transmit complete is exectued just fine here is my routine:

void HAL_UART_TxCpltCallback(UART_HandleTypeDef *huart)
{
	if(huart == &huart5)
	{
		UartReadyTX = true;
		 if(HAL_UART_Receive_IT(&huart5,(uint8_t *)&uartRx[0], 10) != HAL_OK)
		 {
		 Error_Handler();
		 }
 
	}
}

but the receive complete routine gets never called and the HAL RxState of the appropriate UART handle is trapped inside BUSY_RX. I don't understand why.

Like I said the routines worked properly with the blocking mode HAL functions but now with IT functions I am trapped.

Important to notice: When I send a command to the display I get an ACK message back, thats why ever transmit needs an receive in return.

Anyone knows what my mistake is here?

best regards

Benjamin

This topic has been closed for replies.

3 replies

Benjamin Brammer
Senior II
December 12, 2018

Ok I seem to have the problem: I need to specify the correct amount of data to be received. If this isn't the case the receive complete callback is not issued. But here comes the problem: I don't always know how much data is coming back, that's why I just have a receive buffer array. Any solutions how to overcome this problem?

Benjamin Brammer
Senior II
December 13, 2018

ok. I managed to use the UART with dma, works pretty fine so far. For a reason I don't know yet, sometimes the UART DMA receive stays inside the HAL_UART_STATE_BUSY_RX state. This seems to happen on random events, I suggest when timing from display UART doesn't meet the STM32 timing so that the display doesn't send data anymore when I want to issue a next receive. The UART5-SR looks good without an error flag set.

Any suggestions how to trace such random events correctly and find their cause?

Benjamin Brammer
Senior II
December 21, 2018

I might have found the problem. It is no error of the UART peripheral but rather a false ISR triggering. I will check on that the next days and then solve this question..

Piranha
Principal III
December 21, 2018

"I don't always know how much data is coming back, that's why I just have a receive buffer array. Any solutions how to overcome this problem?"

If that's still relevant:

https://stm32f4-discovery.net/2017/07/stm32-tutorial-efficiently-receive-uart-data-using-dma/

https://github.com/MaJerle/STM32_USART_DMA_RX

Benjamin Brammer
Senior II
January 8, 2019

thanks for your post. At the moment I have to debug another custom board, but if I get stuck with that errors again I will check on your post.

THX!