Skip to main content
Andrei1
Associate II
December 11, 2020
Solved

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

  • December 11, 2020
  • 2 replies
  • 4865 views

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?
This topic has been closed for replies.
Best answer by KnarfB

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

2 replies

TDK
Super User
December 11, 2020

> 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
KnarfBBest answer
Super User
December 11, 2020

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

Andrei1
Andrei1Author
Associate II
December 11, 2020

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.

KnarfB
Super User
December 11, 2020

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.