Skip to main content
Explorer
January 21, 2025
Solved

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

  • January 21, 2025
  • 4 replies
  • 6777 views

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

    This topic has been closed for replies.
    Best answer by Mehulrana511

    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

     

    4 replies

    Graduate II
    January 21, 2025

    There was a complaint within last few days of UART7 IRQ on H7

    Super User
    January 21, 2025

    @Mehulrana511 wrote:
    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.

    You need to disconnect the Virtual COM Port (VCP) from UART4 - otherwise it will prevent this setup from working.

    https://community.st.com/t5/stm32-mcus-boards-and-hardware/i-cannot-receive-data-while-using-usb-to-uart-for-nucleo-f411re/m-p/690201/highlight/true#M19855

     

    PS:

    With the VCP connected, you have this:

    UART4 TX ------->+--------------------> UART7 RX
     |
    UART4 RX <-------------+<-------------- UART7 TX
     | ^
     | |
     v |
     VCP VCP
     RX TX

    So the VCP TX and UART7 TX are shorted together - this is why UART7 can receive from UART4, but UART4 cannot receive from UART7.

    Explorer
    January 21, 2025

    Hi @Andrew Neil ,
    Thanks for answering but I need UART4 for debugging purpose.

    One thing I need to add in this thread,
    When I was trying HAL_UART_Receive_IT function and  send cmd from Ethernet, I get response from UART7 but it happens only once(at very first time) then i am not able to get response even after sending same or different cmd.

    But when I use HAL_UARTEx_ReceiveToIdle_IT , I am not able to get response even single time.

    Here is the screenshot of response i get from UART7 when i send cmd from UART7.

     

    Mehulrana511_0-1737461869325.png


    /Mehul 

    Super User
    January 21, 2025

    @Mehulrana511 wrote:

    Thanks for answering but I need UART4 for debugging purpose.


    As noted, you cannot use it both for the VCP and for connection to UART7 (or any other UART) at the same time.

    You can do one or the other - but not both at once.

     


    @Mehulrana511 wrote:

    Here is the screenshot of response i get from UART7 when i send cmd from UART7.


    So how are you connecting UART7 to that terminal?

    Please give full details of your hardware setup:

    https://community.st.com/t5/community-guidelines/how-to-write-your-question-to-maximize-your-chances-to-find-a/ta-p/575228

    Explorer
    January 21, 2025

    Hi,
    I am using the STM32H7S78 microcontroller and the MXCHIP EMC3080-P WiFi/BLE module.

    In my setup:

    1. UART4 and UART7 are enabled on the STM32H7S78.

      • UART4 is dedicated to debugging and is connected to the Virtual COM Port (VCP).
      • I use the Docklight tool on my PC to send commands to UART4.
    2. The flow of data is as follows:

      • A command is sent from the Docklight tool on the PC to UART4.
      • The STM32H7S78 microcontroller receives the command on UART4 via an interrupt.
      • The received command is then forwarded to UART7.
      • The MXCHIP EMC3080-P module, connected to UART7, processes the command and sends a response back to UART7.
      • The STM32H7S78 microcontroller receives the response from UART7 via another interrupt.
      • Finally, the microcontroller sends the received response back to UART4, which prints it on the Docklight tool.

    Here I attached rough diagram for understanding.

    Mehulrana511_0-1737466058178.png

     

    /Mehul

    Graduate II
    January 22, 2025

    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. 

    Super User
    January 23, 2025

    @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

    Mehulrana511AuthorAnswer
    Explorer
    January 27, 2025

    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