SystemCoreClock variable not initialized when needed.

[Aaron McNeil]

When trying to initialize external SRAM in the SystemInit() function in system_stm32lf76xx.c, I call HAL_Init which calls HAL_InitTick. This function calls HAL_SYSTICK_Config which uses the global variable SystemCoreClock to initialize the SysTick. However, it seems like SystemCoreClock is not initialized in memory at the time it is being called here. Are there any workarounds for this?

[Tesla DeLorean]

Perhaps by not using HAL in the pre-initialization stage?

Use register level coding to set clocks, PLLs, pins etc. Make a determination of what these should be by inspecting them from a working example that initializes them later, and within the context of the values described in the Reference Manual.

When the part starts it will be running from the 16 MHz HSI clock.

Perhaps have a small loader which transfers control to the app with the clocks at 216 MHz and the SRAM up and functional, and then don't mess with them again.

[Aaron McNeil]

The Hal Initilization functions seem to be just calling register level coding under the hood. Why is it not a good idea to just make use of these?

[Piranha]

Because HAL functions use tick/delay functions heavily and those use global/static variables and SysTick timer, neither of which is initialized at that stage.

[Aaron McNeil]

Thank you for the response. I did register level initialization and now I am trying to simply toggle an LED for a test. For some reason, in my GPIO register I am toggling the ODR fine but the IDR does not respond and stays at 0x00000000. I am guessing I initialized something wrong here. Any ideas what this could point to?

[waclawek.jan]

> I am toggling the ODR fine

How do you know, does the LED blink?

> the IDR does not respond

Are you reading the IDR of the same port? How do you exactly do that?

JW

[Aaron McNeil]

I could see the ODR register changing in my register map.

I figured out the issue was I was initializing PWR-CR2. The GPIO is responding as expected now.