Clock from CubeMX not applied in VisualGDB on stm32f446

[Artem]

Hello,

I have created an application using CubeMX for a STM32f446. I have exported it as MDK-ARM and imported the project in VisualGDB.

The clocks are setup to use HSE, but when I start the application it uses the HSI clock @64MHz. I have also experimented by re-configuring CubeMX to use HSI clock and change the frequencies but no matter what I set everything seems to get ignored and the application always runs at 64MHz.

When I compile the same application in Keil uVision everything is working as expected – all clocks are set up correctly and HSE clock also works fine.

It looks like VisualGDB is not importing something from the CubeMX generated files. Any ideas?

[support]

Hi,

The clock setup for STM32 devices is normally done by the SystemClock_Config() function. Please try locating it in the files generated by STM32CubeMX (if you cannot find it, try searching for functions calling HAL_RCC_OscConfig()) and then check whether the VisualGDB project includes the file defining this function and whether it is called from your main() function.

[Artem]

Hi,

yes, this is is a standard CubeMX code generation. Actually nothing special. So SystemClock_Config() is there and is being executed. However the settings made there are not applied when compiling with VisualGDB. When compiling the same project using uVision everything works as expected. What can be the difference? Maybe there are some startup files different?

[support]

The actual clock initialization is performed by the SystemClock_Config() function. Hence if the clock is initialized incorrectly, the function either does not get executed, or uses incorrect parameters. The only way to diagnose this is to step through the SystemClock_Config() function in the debugger and double-check the values it sets.

[Artem]

Yeh, I will do some more debugging tomorrow. For now I have the feeling that the CPU is not reset correctly and the clocks are preset by the bootloader or so and can not be changed by the application…

[Artem]

How can I replace the VisualGDB generated startup_stm32f446xx.c with the CubeMX generated startup_stm32f446xx.s ?

[Artem]

Ok, I got a little further: The problem only arises when executing the code via VisualGDB debugger with STLink.  When the system starts after applying power all clocks are correct.

[Artem]

I have modified stm32f4x.cfg from openocd and commented of the following lines. It seems to work now.

Is there any better solution for this?

 

$_TARGETNAME configure -event reset-init {
# Configure PLL to boost clock to HSI x 4 (64 MHz)
#mww 0x40023804 0x08012008 ;# RCC_PLLCFGR 16 Mhz /8 (M) * 128 (N) /4(P)
#mww 0x40023C00 0x00000102 ;# FLASH_ACR = PRFTBE | 2(Latency)
#mmw 0x40023800 0x01000000 0 ;# RCC_CR |= PLLON
#sleep 10 ;# Wait for PLL to lock
#mmw 0x40023808 0x00001000 0 ;# RCC_CFGR |= RCC_CFGR_PPRE1_DIV2
#mmw 0x40023808 0x00000002 0 ;# RCC_CFGR |= RCC_CFGR_SW_PLL

# Boost JTAG frequency
#adapter_khz 8000
adapter_khz 2000

[support]

Hi,

Thanks for finding this out. Normally, the clock-related code in stm32fxxx.cfg would get executed just after starting a debug session. It would raise the system clock frequency, allowing for faster FLASH programming and faster JTAG communication, and once the SystemClock_Config() runs, it would override the parameters set via stm32fxxx.cfg.

The clock parameters set by the stm32fxxx.cfg would only affect the code that runs before SystemClock_Config() (i.e. startup code) and should not affect the rest of the program.

Either way, if you prefer disabling this mechanism, you can copy a modified version of the .cfg file to the project directory and replace the path to it in OpenOCD settings (expand the Advanced view to edit it) to $(ProjectDir.forwardslashes)/<cfg file name>.

Regarding the startup file, VisualGDB normally does not allow replacing it because the file shipped with VisualGDB is 100% equivalent to the original .s file. It only defines the interrupt vector table and the reset handler and does not handle the clock. If you absolutely need to override it, please consider setting the “excluded from build” flag for the .c file and adding the .s file to the project manually.

[janulo]

Hello,

First of all, thank you Artem for your posts, it helped me to find out what is the issue in my case 🙂

I had similar issue with STM32L471. It turned out, that problem was not with changing of MSI clock (from 4MHz to 24MHz to boost jtag) by debugger, but with disabling instruction cache when writing into FLASH_ACR register (in order to set flash latency and enable prefetch). My init code didn’t set cache on/off at all, and therefore I had different behavior when starting using debugger (which disabled instr. cache) compared to restart by application itself (which kept instr. cache enabled as this is the default state after reset).

So maybe not that much related to your issue Artem, but maybe it’s worth to check if you are configuring everything, what was touched by debuger, in your init code (even something not that much related to clock as instruction cache).

Here is the part of openocd cfg (stm32l4x.cfg in my case), which was modifying cache configuration – first mww instruction touching FLASH_ACR register:

$_TARGETNAME configure -event reset-init {
	# CPU comes out of reset with MSI_ON | MSI_RDY | MSI Range 6 (4 MHz).
	# Use MSI 24 MHz clock, compliant even with VOS == 2.
	# 3 WS compliant with VOS == 2 and 24 MHz.
	mww 0x40022000 0x00000103   ;# FLASH_ACR = PRFTBE | 3(Latency)
	mww 0x40021000 0x00000099   ;# RCC_CR = MSI_ON | MSIRGSEL | MSI Range 9
	# Boost JTAG frequency
	adapter_khz 4000
}

Regards

Jan

[Nh0SF7W]

Hey,

I ran into these issues as well using the STM32F4 discovery board. The thing that was really odd for me was that an example from the STM32CubeIDE would work from the STM32CubeIDE but not in VisualGDB even though both were using OpenOCD. I discovered the STM32CubeIDE had a slightly different configuration for the OpenOCD file.

 

$_TARGETNAME configure -event reset-init {
global _CLOCK_FREQ

echo "configuring PLL"
# Configure PLL to boost clock to HSI x 8 (64 MHz)
mww 0x40023800 0x00008a81 ;# RCC_CR = HSICAL[bogus = 138] | HSITRIM[16] | HSION (reset value)
mww 0x40023808 0x00000000 ;# RCC_CFGR = (all = div1), select HSI as main clock source. (reset value)
mww 0x4002380c 0x00000000 ;# RCC_CIR = 0, all off. (reset value)
mww 0x40023804 0x24403010 ;# RCC_PLLCFGR = PLLQ[div4] | PLLSRC[HSI] | PLLP[div2] | PLLN[mul192] | PLLM[div16] (reset value)
mww 0x40023c00 0x00000103 ;# FLASH_ACR = PRFTEN | LATENCY[2] (we'll run at 84 MHz, see section 3.5.1, table 10 and table 11)
mww 0x40023800 0x01008a81 ;# RCC_CR = PLLON | HSICAL[bogus = 138] | HSITRIM[16] | HSION (enable PLL)
sleep 10 ;# Wait for PLL to lock
mww 0x40023808 0x00000002 ;# RCC_CFGR = (all = div1), select PLL as main clock source. (we should now run at 84 MHz)

adapter speed $_CLOCK_FREQ
}

Sincerely,

Nh0SF7W

• This reply was modified 2 years, 10 months ago by Nh0SF7W.

[support]

Hi,

Indeed, the STM32CubeIDE comes with its own fork of OpenOCD and slightly different scripts. You can install an equivalent of it by selecting OpenOCD (ST Fork) as the debug method instead of the regular OpenOCD. Please note that this requires VisualGDB 5.6 or later.

[gismilyk]

Hi, all!

for a long time I’ve been having the same problem – a nice working program jumpes to HAL_Error callback every time I press F5. As it was shown in Artem’s posts, something wrong was (allegedly) in openocd config files.
I looked at the clock settings when my program was halted in the callback – they were settings from stm32F4x.cfg, not from CubeMX settings.
Finally, it seems I found the reason of strange clock settings with a debugger attached.

The stm32F4x.cfg contains following lines

    mmw 0x40023800 0x01000000 0 ;# RCC_CR |= PLLON

    sleep 10                    ;# Wait for PLL to lock

    mmw 0x40023808 0x00001000 0 ;# RCC_CFGR |= RCC_CFGR_PPRE1_DIV2

    mmw 0x40023808 0x00000002 0 ;# RCC_CFGR |= RCC_CFGR_SW_PLL

which turns PLL on and make it a System Clock Source (the last one).
If a program (as it is in my case) uses Cube generated SystemClock_Config() to set up clocks, it calls large HAL function HAL_RCC_OscConfig from stm32f4xx_hal_rcc.c, where one may find the following lines:

/* Check if the PLL is used as system clock or not */

if(__HAL_RCC_GET_SYSCLK_SOURCE() != RCC_CFGR_SWS_PLL)

…

That is if System Clock Source is already PLL we finally get a HAL_Error. If not, PLL will be set up according to CubeMX settings.

You may consider this as HAL bug or feature at your taste 😊
Here is simple cure for this ‘feature’:
In my main.cpp I’ve added the following:

/* Configure the system clock */

#ifdef DEBUG

if (__HAL_RCC_GET_SYSCLK_SOURCE() == RCC_CFGR_SWS_PLL)

HAL_RCC_DeInit();

#endif

SystemClock_Config();

/* USER CODE BEGIN SysInit */

DeInit does the job – now when SystemClock_Config() is called it runs the right way.

Note, that I’ve added  this snippet outside the USER CODE comments, so it will be deleted if you re-generate the code from STM32CubeIDE.

Hope this may be helpful.

[support]

Hi,

Thanks very much for sharing this!

[Author]

Posts