legacy interrupt handlers in cubemx 6.6.0

[ksale.1]

I'm trying to get into UART interrupt. It used to be copying the 'weak' function declaration and declare our own in main such as:

main()
{
....
void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart)
{
 
 
// usr code here
 
}
....
}
 

However, this apparently became legacy. Now I get the following:

"stm32h7xx_it.c"

"stm32h7xx_it.c"
 
**
 
 * @brief This function handles USART3 global interrupt.
 
 */
 
void USART3_IRQHandler(void)
 
{
 
 /* USER CODE BEGIN USART3_IRQn 0 */
 
 
 
 /* USER CODE END USART3_IRQn 0 */
 
 HAL_UART_IRQHandler(&huart3);
 
 /* USER CODE BEGIN USART3_IRQn 1 */
 
 
 
 /* USER CODE END USART3_IRQn 1 */
 
}
 

Please advise an App Note describing how we handle the interrupt the same way we used to do.

[KnarfB]

HAL_UART_IRQHandler will analyze the interrupt and call HAL_UART_RxCpltCallback and others as appropriate. Use a debugger and step into HAL_UART_IRQHandler to find out what happens.

Don't know if that works with your nested function HAL_UART_RxCpltCallback. This is not standard C but a GNUism.

hth

KnarfB

[Piranha]

The first code defines function in a function.

The second code was always like that.

The new approach uses HAL_UART_RegisterCallback() and HAL_UART_RegisterRxEventCallback(). It solves the problem of multiple peripheral instances, but it still uses a separate callback function for each event type. In the end it's still an incompetent design...

[ksale.1]

Please note I've erred in my message, the function in the first code is not nested, but before main as follows:

void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart)
{
 
 
// usr code here
 
}
 
 
main()
{
....
}

Thank you for your support

[ksale.1]

I used the legacy code successfully using MVP (Model View Presenter), but lost my way with the new approach , I would like to have an App note about it and/or examples.

[Pavel A.]

@ksale.1​ So do you want to use the "new approach" (per-instance callbacks) or keep using the "legacy" callbacks?

CubeMX 6.6.0 does not introduce any change in these, the same two approaches existed before it.

If you upgraded to 6.6.0 and something broke, it is because of something else (maybe, move to a newer version of the underlying "HAL" library?)

[ksale.1]

@Pavel A.​ my preference is to continue using the legacy callbacks. The project created by the touchgfx designer 4.20.0 uses the new approach, that is why I need a good grasp on the issue.

[Pavel A.]

Ok then. Open your CubeMX/IDE project (,ioc) and go to Project Manager-> Advanced settings.

On the right side there is "Register Callback" pane. There you can define which "HAL" library module uses the per-instance callbacks.

This choice is generated into stm32??xx_hal_conf.h :

Look for sequence of lines like:

#define USE_HAL_***_REGISTER_CALLBACKS     1U

​

Then look in the HAL source files how you can specify these callbacks and how the HAL driver calls them.

Usually HAL drivers initialize the callbacks pointers in the instance with the "legacy" callback functions. If some of these already exist in the user code, and not overridden per-instance, they should be called. Otherwise they resolve to the default weak no-op functions in the HAL drivers.

Basically that's all (plus the comment of @Piranha​ above ;)

[ksale.1]

Thank you @Pavel A.​ , please note the below sceenshots

 

Please note I couldn't locate the file stm32h7xx_hal_conf.h in the project tree. Please advise.

[Pavel A.]

After enabling the callback you still have the USART1_IRQHandler.

The stm32h7xx_hal_conf.h should be in Core/Inc (or maybe generated/Inc for emWin projects). Use dir /s command to find.

[ksale.1]

Hi @Pavel A.​ , I started the project in TouchGFX designer and it generated the STM32CubeIDE project, and from there I open the cube mx ioc file etc.... As you can see the project tree is not the customary "inc\src" branches. I'll try a simple project and debug through it and come back with my understanding. Thank you.

[ksale.1]

I've got the code compiled successfully but with IDE v1.8.0, MX v6.3.0, GFX v4.18.0. I have not yet received the discovery board to life-test it though. However, this is not the sought for solution, I still need link to AN on the subject.

[redmig]

Expand the Includes. The first item should be Core/Inc of your project, where you should find stm32h7xx_hal_conf.h and all the others included header files.

[Tesla DeLorean]

The IRQHandlers has *always* been how interrupts are serviced, what the code does is call into the HAL so it can call your call-backs once it qualifies the source and determines the mode of dispatch.

The HAL adds a lot of unnecessary layers, and one should remain cognizant that call-backs are called under interrupt context, with the limits and expectations that come with that. ie that they block other interrupts, and should complete quickly, without blocking functions, or ones spinning on timeouts.