Clock from CubeMX not applied in VisualGDB on stm32f446

Sysprogs forums Forums VisualGDB Clock from CubeMX not applied in VisualGDB on stm32f446

Tagged: 

This topic contains 9 replies, has 3 voices, and was last updated by  janulo 1 month, 3 weeks ago.

Viewing 10 posts - 1 through 10 (of 10 total)
  • Author
    Posts
  • #26940

    Artem
    Participant

    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?

    #26941

    support
    Keymaster

    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.

    #26942

    Artem
    Participant

    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?

    #26943

    support
    Keymaster

    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.

    #26944

    Artem
    Participant

    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…

    #26945

    Artem
    Participant

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

    #26946

    Artem
    Participant

    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.

    #26947

    Artem
    Participant

    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

    #26951

    support
    Keymaster

    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.

    #27375

    janulo
    Participant

    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:

    Regards

    Jan

Viewing 10 posts - 1 through 10 (of 10 total)

You must be logged in to reply to this topic.