AnsweredAssumed Answered

Receptions issues in interrupt driven IO with USART2 when HAL_UART_Receive_IT() is called before HAL_UART_Transmit_IT()

Question asked by thy on Jul 14, 2016
Latest reply on Aug 22, 2016 by FTITI.Walid
Hi there,


here it is the environment: custom board with stm32f427, Cube FW 1.11, freeRTOS, eclipse mars.


This is the scenario: UART IO with a bluetooth module via USART2 peripheral. I send some strings and receive others. There are two tasks, say TxTask and RxTask: TxTask transmits while RxTask receives by using HAL_UART_Transmit_IT and HAL_UART_Receive_IT, respectively. In turn each one of such tasks communicate with queues with two corresponding tasks which operate low priority jobs related to the transmitted and received strings. Receptions are one char at a time until a condition (i.e. \n received) is not met while at this stage transmissions are fixed length strings. The micro transmits periodically a string (every 500 ms) and receive from a remote user through a tablet some commands ending with \n. So at the very beginning TxTask starts to transmit and RxTask waits in reception.


This is the expected behavior: if HAL_UART_Receive_IT is called before HAL_UART_Transmit_IT (and this ultimately depends upon the scheduler), then should be UART_Handle.RxState = HAL_UART_STATE_BUSY_RX until something is not received and regardless the transmission operations.


This is what happens: when HAL_UART_Receive_IT(&UART_Handle, &ch, 1) is called before HAL_UART_Transmit_IT, after a while (I was not able to catch when) UART_Handle.RxState = HAL_UART_STATE_READY even if nothing has been received (the ISR has not been called), UART_Handle.RxXferSize = 64, UART_Handle.RxXferCount = 63, and clearly I cannot receive anything. The peripheral's reception buffer pointer points to the correct memory location &ch and, this is very odd, 64 corresponds to the transmitted string length.


My patch: if I put a delay, within RxTask before entering the main loop, big enough to allow transmissions starting before receptions, then everything works very fine, on the contrary, since seems the scheduler starts RxTask before TxTask, I meet with what I have previously described.


Here down below some code:
01.static HAL_StatusTypeDef UART_BLUETOOTH_WriteData_IT(uint8_t *pBuffer, uint16_t Size)
02.{
03.  HAL_StatusTypeDef status = HAL_OK;
04. 
05.  xTaskToNotifyTx = xTaskGetCurrentTaskHandle(); /* This is a freertos notification facility used with the tx callback */
06. 
07.  status = HAL_UART_Transmit_IT(&UART_BLUETOOTH_Handle, pBuffer, Size);
08. 
09.  if(ulTaskNotifyTake(pdTRUE, IO_TX_TIMEOUT/portTICK_PERIOD_MS) == 1)
10.  {
11.      if(status != HAL_OK)
12.      {
13.          UART_BLUETOOTH_Error();
14.      }
15. 
16.      return status;
17.  }
18. 
19.  else return HAL_TIMEOUT;
20.}
21. 
22.static HAL_StatusTypeDef UART_BLUETOOTH_ReadData_IT(uint8_t *pChar)
23.{
24.    xQueueReceive(bluetoothRxQueueH, pChar, portMAX_DELAY);
25. 
26.    return HAL_OK;
27.}
28.static void bluetoothRxTask(void const *pvParameters)
29.{
30.    uint8_t ch = 0;
31. 
32.    vTaskDelay(30000/portTICK_PERIOD_MS); /* This is the "big enough" delay */
33. 
34.    while(1)
35.    {
36.        xTaskToNotifyRx = xTaskGetCurrentTaskHandle(); /* This is a freertos notification facility used with the rx callback */
37. 
38.        HAL_UART_Receive_IT(&UART_BLUETOOTH_Handle, &ch, 1);
39. 
40.        ulTaskNotifyTake(pdTRUE, portMAX_DELAY);
41. 
42.        xQueueSendToBack(bluetoothRxQueueH, &ch, portMAX_DELAY);
43.    }
44.}
45. 
46.void bluetoothReceiveCallback(UART_HandleTypeDef *huart)
47.{
48.    BaseType_t xHigherPriorityTaskWoken = pdFALSE;
49. 
50.    vTaskNotifyGiveFromISR(xTaskToNotifyRx, &xHigherPriorityTaskWoken);
51. 
52.    xTaskToNotifyRx = NULL;
53. 
54.    portYIELD_FROM_ISR(xHigherPriorityTaskWoken);
55.}
56. 
57.void bluetoothTransmitCallback(UART_HandleTypeDef *huart)
58.{
59.    BaseType_t xHigherPriorityTaskWoken = pdFALSE;
60. 
61.    vTaskNotifyGiveFromISR(xTaskToNotifyTx, &xHigherPriorityTaskWoken);
62. 
63.    xTaskToNotifyTx = NULL;
64. 
65.    portYIELD_FROM_ISR(xHigherPriorityTaskWoken);
66.}

Can anybody provide me some insight or, maybe, confirm a bug in the HALs?


Regards.

Outcomes