Can't receive data on UART7 in STM32H7S78-DK while using UART4

[Mehulrana511]

Hello,

I am using the STM32H7S78-DK board and STM32CubeIDE for development. In my application, I am working with UART communication between UART4 and UART7.

Objective:

1. I am sending data from UART4 (connected to the Virtual COM port on the board).
2. The data is transmitted from UART4 to UART7.
3. After sending the data, I expect a response from UART7, but I am unable to receive it.

Steps I Follow:

1. Initially, I used the HAL_UART_Receive_IT function for UART7 reception. However, upon reviewing several posts and technical documents, I realized that HAL_UART_Receive_IT is only suitable for known-length data and not for unknown-length data.
2. Based on the reference example provided here, I implemented HAL_UARTEx_ReceiveToIdle_IT for idle-line detection.

Issue Faced:

Despite implementing HAL_UARTEx_ReceiveToIdle_IT, I am still unable to receive any response from UART7.

Here is my code for reference,

/* USER CODE BEGIN PV */
#define RX_BUFFER_SIZE      20
#define RX_BUFFER_SIZE_7    50

uint8_t rxBuffer[RX_BUFFER_SIZE] = {0}; // Buffer to store received data
uint8_t rxBuffer7[RX_BUFFER_SIZE_7] = {0}; // Buffer to store received data


osThreadId_t uartTaskHandle;
const osThreadAttr_t uartTask_attributes =
{
    .name = "uartTask",
    .priority = (osPriority_t)osPriorityNormal,
    .stack_size = 512 * 4,
};

void UART_Print(const char* message)
{
   // Transmit the string data over UART
   HAL_UART_Transmit(&huart4, (uint8_t*)message, strlen(message), HAL_MAX_DELAY);
}


void SendDataOnUART7(uint8_t *pData)
{
	uint8_t TxData[20];

	uint16_t length = (uint16_t)pData[0];

	memcpy(TxData, &pData[1],length);

	// Transmit the string data over UART
	HAL_UART_Transmit(&huart7,TxData, length, HAL_MAX_DELAY);
}


void HAL_UARTEx_RxEventCallback(UART_HandleTypeDef *huart, uint16_t Size)
{
	if (huart->Instance == huart7.Instance)
	{
		// Transmit the string data over UART
		printf("Received data on uart7: %s\n\r", rxBuffer7);

		HAL_UARTEx_ReceiveToIdle_IT(&huart7, rxBuffer7, RX_BUFFER_SIZE_7);
	}
}


void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart)
{
	if (huart->Instance == huart4.Instance)
	{
		// Print received message
		printf("Received: %s\n\r", rxBuffer);

		SendDataOnUART7(rxBuffer);

		memset(rxBuffer, 0, RX_BUFFER_SIZE);

		// Re-enable UART interrupt for the full buffer to receive more data
		HAL_UART_Receive_IT(&huart4, rxBuffer, RX_BUFFER_SIZE);
	}

}


/**
  * @brief  The application entry point.
  * @retval int
  */
int main(void)
{

  /* USER CODE BEGIN 1 */

  /* USER CODE END 1 */

  /* MPU Configuration--------------------------------------------------------*/
  MPU_Config();

  /* Enable the CPU Cache */

  /* Enable I-Cache---------------------------------------------------------*/
  SCB_EnableICache();

  /* Enable D-Cache---------------------------------------------------------*/
  SCB_EnableDCache();

  /* MCU Configuration--------------------------------------------------------*/

  /* Update SystemCoreClock variable according to RCC registers values. */
  SystemCoreClockUpdate();

  /* Reset of all peripherals, Initializes the Flash interface and the Systick. */
  HAL_Init();


  MX_GPIO_Init();
  MX_HPDMA1_Init();
  MX_LTDC_Init();
  MX_CRC_Init();
  MX_DMA2D_Init();
  MX_JPEG_Init();
  MX_FLASH_Init();
  MX_I2C1_Init();
  MX_GPU2D_Init();
  MX_ICACHE_GPU2D_Init();
  MX_UART4_Init();
  MX_UART7_Init();
  
  UART_Print("Start...TouchGFX...Project\n\r");
  printf("Hello_STM32H7S78-DK!\n\r");

  /* Enable UART4 interrupt mode */
  //Make sure that the data sent is exactly 20 bytes, as the RX_BUFFER_SIZE is set to 20. If the data is not 20 bytes, it will not work properly!
  HAL_UART_Receive_IT(&huart4, rxBuffer, RX_BUFFER_SIZE); 
  HAL_UARTEx_ReceiveToIdle_IT(&huart7, rxBuffer7, RX_BUFFER_SIZE_7);


  MX_TouchGFX_Init();
  /* Call PreOsInit function */
  MX_TouchGFX_PreOSInit();

  osKernelInitialize();

  defaultTaskHandle = osThreadNew(StartDefaultTask, NULL, &defaultTask_attributes);

  /* creation of TouchGFXTask */
  TouchGFXTaskHandle = osThreadNew(TouchGFX_Task, NULL, &TouchGFXTask_attributes);

  uartTaskHandle = osThreadNew(UART_Task, NULL, &uartTask_attributes);


  /* Start scheduler */
  osKernelStart();

  while (1)
  {

  }
  /* USER CODE END 3 */
}

I would appreciate any guidance or example code to resolve this issue.

Best regards,
Mehul

[Karl Yamashita]

So I've tested on the Nucleo-H723 and UART7 is interrupting. 

The first time I tested, it was over a year ago. Possibly the FW package back then could have had a bug? I never did check the generated code for bugs back then.

But with STM32CubeIDE 1.16.1 and the latest FW package, UART7 doesn't show any issue with interrupts when receiving data. 

[Andrew Neil]

---

@Karl Yamashita wrote:

So I've tested on the Nucleo-H723 and UART7 is interrupting.  

---

@Mehulrana511 has also confirmed that they have UART7 interrupts working when they don't also use UART4.

So it's certainly not a fundamental issue with UART7 interrupts.

A already noted, I strongly suspect the fault(s) is/are in @Mehulrana511 and @harshpanchal_6's code

[Mehulrana511 · Accepted solution]

Hi @Andrew Neil ,

Thank you for your response!

We have identified the bug. The interrupt is being blocked due to the printf function, as it transmits data over UART4 at the same time when we receive an interrupt on UART7.

Here’s what I did to resolve it:

I am now sending the data (command) through Ethernet and transmitting this data over UART7. Once I get a response from UART7, I wait for one byte of data. Since I am unsure of the exact length of the received data, I treat the reception as complete when I encounter a '\n' character. After this, I send the data over Ethernet.

During this operation, I avoid using the printf function (on UART4). In other scenarios, I can continue using printf for debugging purposes.

Thank you once again for your help!

Best regards,
Mehul

[Andrew Neil]

Glad you've resolved it.

A couple of notes:

---

@Mehulrana511 wrote:

The interrupt is being blocked due to the printf function, as it transmits data over UART4 at the same time when we receive an interrupt on UART7.

---

printf is not inherently linked to any particular output device - you can configure it however you like.

Also, printf is not inherently blocking - you could use non-blocking output.

eg, see: https://community.st.com/t5/stm32-mcus/how-to-redirect-the-printf-function-to-a-uart-for-debug-messages/ta-p/49865 (UART)

Also: https://community.st.com/t5/stm32-mcus/using-the-itm-console-for-printf-redirects-and-lwip-debug/ta-p/723472 (ITM console)