cancel
Showing results for 
Search instead for 
Did you mean: 

DCT Issue: Missing HAL Interrupt Handler for USART6

tykhaytschaar
Associate II

Hi everyone,

I'm encountering an issue with the STM32 Device Configuration Tool: it doesn't properly generate the global interrupt handler function for one of the UARTs in my project: 

The generated interrupt handlers for USART1 and USART2 include call of the default HAL interrupt handler (HAL_UART_IRQHandler(&huartX);) but the handler for USART6 is missing this line.

 

/**
  * @brief This function handles USART1 global interrupt.
  */
void USART1_IRQHandler(void)
{
  /* USER CODE BEGIN USART1_IRQn 0 */

  /* USER CODE END USART1_IRQn 0 */
  HAL_UART_IRQHandler(&huart1);
  /* USER CODE BEGIN USART1_IRQn 1 */

  /* USER CODE END USART1_IRQn 1 */
}

/**
  * @brief This function handles USART2 global interrupt.
  */
void USART2_IRQHandler(void)
{
  /* USER CODE BEGIN USART2_IRQn 0 */

  /* USER CODE END USART2_IRQn 0 */
  HAL_UART_IRQHandler(&huart2);
  /* USER CODE BEGIN USART2_IRQn 1 */

  /* USER CODE END USART2_IRQn 1 */
}

/**
  * @brief This function handles USART6 global interrupt.
  */
void USART6_IRQHandler(void)
{
  /* USER CODE BEGIN USART6_IRQn 0 */
  // missing from here:
  /* USER CODE END USART6_IRQn 0 */
  /* USER CODE BEGIN USART6_IRQn 1 */

  /* USER CODE END USART6_IRQn 1 */
}

 

Project Details:

  • Project: coprocessor_ica
  • Processor: STM32F411CEU
  • Configuration:
    • 3 UARTs configured in the .ioc file (asynchronous mode, using DMA for both TX and RX)
    • Global (and DMA) interrupts enabled for all three UARTs
    • Using HAL drivers

Problem:

  • The generated interrupt handlers for USART1 and USART2 include the default HAL interrupt handler call (HAL_UART_IRQHandler(&huartX);), but the handler for USART6 is missing this line.

Observations:

I have another project (coprocessor_vica) with the same processor and a very similar configuration.

  • The main differences are the pin names and an additional timer configured in coprocessor_vica.
  • In this project, the issue doesn't occur.

To investigate, I:

  • Backed up the coprocessor_ica.ioc file.
  • Copied the coprocessor_vica.ioc file into the coprocessor_ica directory and replaced all "vica" strings with "ica" using a text editor.
    • After regeneration, the interrupt handler issue was resolved in coprocessor_ica.
  • Renamed the pins and removed the extra timer to match the original coprocessor_ica setup.
    • The issue reappeared.
  • I created a new project from the original(ly faulty) coprocessor_ica.ioc in a different workspace, and generated the code. The handler call is still missing.

Questions:

  1. What could be causing this behavior?
  2. Are there any logs for the code generation process where I could trace where the issue occurs?

Environment:

  • ST32CubeIDE:
    • Version: 1.16.1
    • Build: 22882_20240916_0822 (UTC)
  • STM32CubeMX:
    • Version: 6.12.1-RC4
    • Build: 20240912-2256 (UTC)
  • Platform:
    • Apple M1
    • macOS Sequoia 15.2 (24C101)

I've attached both .ioc files.
Thanks in advance for any insights or advice!

1 ACCEPTED SOLUTION

Accepted Solutions
tykhaytschaar
Associate II

@SofLit 
I found the cause, and it was (partly?) my mistake: in the System Core > NVIC > Code Generation tab, the Call HAL handler checkbox for the USART6 Global Interrupt was not checked. After enabling it, the code generation works correctly.

However, there are still a few things I don't understand:

  • How could the checkbox become unchecked without deliberate user interaction?
  • How is it possible that copying another working .ioc file and than modifying some pin names and enabling a timer also resulted in the same issue?
  • How is it possible that the same .ioc file worked correctly for you? (I assume the checkbox is checked in your case if the generation works as expected.)

tykhaytschaar_0-1736359144050.png

 

View solution in original post

10 REPLIES 10
SofLit
ST Employee

Hello @tykhaytschaar ,

I'm not reproducing the behavior for both projects and HAL_UART_IRQHandler() is there:

SofLit_0-1736343313854.png

Please use the latest version of CubeMx 6.13.0

To give better visibility on the answered topics, please click on "Accept as Solution" on the reply which solved your issue or answered your question.

Thanks for the prompt response, @SofLit .
In the meantime I tried to generate code on an ubuntu 22.04 machine with fresh installation of cubeIDE.
STM32CubeMX - STM32 Device Configuration Tool
Version: 6.13.0-RCS
Build: 20241122-0809 (UTC)

The issue occurs on this machine also.

Edit:

 

cubemx.png

I don't have neither Ubuntu machine nor MacOS to reproduce the exact environnement as yours I'm on windows and didn't reproduce the behavior.

Did you download CubeMx from this link?

From where you downloaded  the version 6.13.0-RCS ?

To give better visibility on the answered topics, please click on "Accept as Solution" on the reply which solved your issue or answered your question.
tykhaytschaar
Associate II

I've downloaded official STM32CubeIDE installer from here: https://www.st.com/en/development-tools/stm32cubeide.html (chose "STM32CubeIDE Generic Linux Installer 1.17" exactly. CubeMX came as part of the IDE, so selecting RCS wasn't my decision.

SofLit
ST Employee

Ah! So try to generate the code from the standalone version of CubeMx 6.13.0 and see what happens. It could be an issue in the CubeMx version integrated in the CubeIDE.

To give better visibility on the answered topics, please click on "Accept as Solution" on the reply which solved your issue or answered your question.
tykhaytschaar
Associate II

I installed the standalone version of CubeMX on the ubuntu machine and tried generating the code with it as well. The issue still persists.

cubemx2.png

Could you copy your ioc file to another location and regenerate the code with the standalone version of CubeMx and see what happens?

To give better visibility on the answered topics, please click on "Accept as Solution" on the reply which solved your issue or answered your question.

I did, the result is the same.

Ok since I don't have the same environment as yours I will escalate the issue internally so the teams will try to reproduce the behavior on the same environment. Internal ticket for follow-up: 199844 (not accessible by the community users)

To give better visibility on the answered topics, please click on "Accept as Solution" on the reply which solved your issue or answered your question.