cancel
Showing results for 
Search instead for 
Did you mean: 

legacy interrupt handlers in cubemx 6.6.0

ksale.1
Senior

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.

1 ACCEPTED SOLUTION

Accepted Solutions

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 ;)

View solution in original post

13 REPLIES 13
KnarfB
Principal III

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
Chief II

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
Senior

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
Senior

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.

@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
Senior

@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.

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
Senior

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

0693W00000QKaCHQA1.png0693W00000QKaCRQA1.png 

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

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.