cancel
Showing results for 
Search instead for 
Did you mean: 

HAL Peripheral MSP Init. Why does STM32CubeIDE generated code not include a call to this function?

Andrei1
Associate II

I made a UART project in STM32CubeIDE. Cube generated the necessary UART initialisation code and created UART_INIT() function (or something like that) in main(). The project worked.

Then I decided to add DMA. I regenerated the code and couldn't find DMA initialisation in UART_INIT(). I found out that this code was generated in another file in UART_MSP_INIT() function (or something like that). My questions are:

  • Why does Cube generate this code in another file? Why not in UART_INIT() or DMA_INIT() in main()?
  • Do I have to explicitly call UART_MSP_INIT() in main() by myself? And why doesn't Cube do it automatically?
  • I found out that GPIO alternate function configuration (for UART) was also made in UART_MSP_INIT(). But I did't explicitly call UART_MSP_INIT() before using DMA. So why did UART work if the pins were not configurated?
1 ACCEPTED SOLUTION

Accepted Solutions
KnarfB
Principal III

The HAL files under Drivers are used for several chips. That code doesn't change. The chip/project configuration maps to files in Core/Src. Thats main() calling MX_USART2_UART_Init(); for example. That function fills a setup struct and calls a somehow generic HAL function HAL_UART_Init() which in turn calls HAL_UART_MspInit() in Core/Src stm32f0xx_hal_msp.c which inits the underlying components like the GPIOs.

Try debug-stepping through the init code to get the idea.

MSP = MCU Support Package

hth

KnarfB

View solution in original post

4 REPLIES 4
TDK
Guru

> Why does Cube generate this code in another file? Why not in UART_INIT() or DMA_INIT() in main()?

Who knows, it is what it is. But they should NOT be called from within UART_Init, so it doesn't make perfect sense to locate them there.

> Do I have to explicitly call UART_MSP_INIT() in main() by myself? And why doesn't Cube do it automatically?

It's called within HAL_UART_Init and should not be called by yourself. Cube does call it automatically.

> I found out that GPIO alternate function configuration (for UART) was also made in UART_MSP_INIT(). But I did't explicitly call UART_MSP_INIT() before using DMA. So why did UART work if the pins were not configurated?

Because it was called and they were configured.

If you feel a post has answered your question, please click "Accept as Solution".
KnarfB
Principal III

The HAL files under Drivers are used for several chips. That code doesn't change. The chip/project configuration maps to files in Core/Src. Thats main() calling MX_USART2_UART_Init(); for example. That function fills a setup struct and calls a somehow generic HAL function HAL_UART_Init() which in turn calls HAL_UART_MspInit() in Core/Src stm32f0xx_hal_msp.c which inits the underlying components like the GPIOs.

Try debug-stepping through the init code to get the idea.

MSP = MCU Support Package

hth

KnarfB

Before explicitly calling HAL_UART_MspInit() in main() I actually made a breakpoint in it to find out if the function is called or not. And the program didn't stop there. That's why I assumed that this function is not called automatically. Maybe I just made a mistake.

You're not supposed to call the *_MspInit functions. HAL has a default "do nothing" implementation defined "weak" for the linker. For the peripherals in use, those are "overloaded" by the implementation in stm32f0xx_hal_msp.c. Some call it software design, others bloatware.