STM32 clock gets modified when debugger is connected

[matbob]

Hello Everyone,

I have a custom board with STM32F030K6T. I have configured the PLL to generate 48 MHz clock for the core and peripherals. I am generating PWM outputs using TIM1 at 5 KHz. I am seeing a strange problem. When I connect a debugger (SWD) to the board and debug using SW4STM32 (System Workbench for STM32), the PWM output frequency changes to 2.5 KHz. If I remove the debugger and reset the microcontroller and runs it again, I get the correct 5 KHz frequency output. Anyone has encountered similar problems before? This happens irrespective of the clock source, I tried with HSI and HSE clock sources (both at 8 MHz) as the input to the PLL.

The PLL configuration is done using CubeMX. When debugging, I could see that the clock configuration function (SystemClock_Config()) is called correctly and does not return any error or calls the Error_Handler() function. So I am assuming that the clock configuration is happening correctly. The Flash Latency (Wait States) is set as 2 CPU cycles by CubeMX for 48 MHz operation.

I tried with 2 different debuggers, one cheap Chinese clone of ST-LINK V2 and another Nucleo board based debugger. Both debuggers are giving me the same result. I tried outputting the PLL frequency through the clock output pin (RCC_MCO) and it gives me 24 MHz (which gives me 2.5 KHz PWM frequency) when running with the debugger and 48 MHz when running without the debugger connected. I am puzzled why the clock frequency is changing.

Thanks.

[Yansi]

That sounds like some strange fuckup. There is no reason the system clock should change, nor there is any relationship in between the system PLL and debugger connection.

If such strange change happens, I'd suspect your debbuger software is writing somewhere it shouldn't. So, what software do you use for debugging? What toolchain?

Also, after connecting your debugger, dump out all the PLL and clock related registers (RCC peripheral) and observe obvious problems there, if something gets written to.

(Subscribing to this thread, interested to know what it is caused by.)

[matbob]

Hello Yansi,

Thanks for your reply. I am using CubeMX 5.6.1 for initial configuration, System Workbench for STM32 IDE, gdb and OpenOCD with STLink V2 for debugging.

I checked RCC registers while debugging. Interestingly, I found that the value in PLLSRC is always 00 and PLLMUL is always 0100 irrespective of any clock configuration in CubeMX. This corresponds to 8 MHz HSI clock with a division of 2 and PLL multiplication factor of 6 giving 24 MHz clock. The parameters in the SystemClock_Config() function gets modified correctly when I change the parameters in CubeMX, however the registers are taking different values.

Attached is the screen shot of the RCC registers.

[matbob]

I dumped the RCC_CFGR value through UART when running standalone without the debugger and got the value as 0x0011000A. This corresponds to HSE clock (8 MHz) with no division and PLL scale of 6, resulting in the correct 48MHz clock.

With the debugger, the value was 0x0010000A. This corresponds to HSI (not HSE) clock (8 MHz) with division of 2 and PLL scale of 6, resulting in the wrong 24 MHz clock.

 

[ace1903]

I run into this same issue with STM32F071. Additionally, this micro has "errata" that some PLL combinations are forbidden.
When debugging, clocks are all over the place.
I narrowed down to file stm32f0x.cfg and procedures
stm32f0x_default_reset_init and configure -event reset-init

I can manually edit those scripts but because I am using sw4stm and AC6 IDE, IDE detects changes into the file that is protected by a checksum called the environment and overwrites my settings with default ones.

Want to switch to STM32CubeIde but I am not sure if I will get the same behavior.

I asked on ST forum for a solution but no answer till now.
Any IDE that will allow me to use my own scripts will fix the issue.

[matbob]

Hello ace1903,

Thanks for your help. I was able to find the problem. The OpenOCD configuration file "stm32f0x.cfg" has a bug. Attached is a screen shot of a section of the file in which it configures the clock for 48 MHz.

The RCC_CFGR register is configured with a wrong value. It should be 0x00280000 (PLL multiplication of 12) instead of 0x00100000 (PLL multiplication of 6) since the HSI clock is divided by 2 before going to the PLL. I modified this configuration file and it is working okay now.

[Yansi]

Why should a fucking  OpenOCD even touch these registers without the consent of the programmer?

[ace1903]

OpenOCD needs to initialize the flash controller in order to program the memory.
I am OK with that.
For me the problem is that scripts is located in debug plug in:
C:\Ac6\SystemWorkbench\plugins\fr.ac6.mcu.debug_2.5.0.201904120827\resources\openocd\st_scripts\target\stm32f0x.cfg

Maybe when IDE is restarted or fetches some updates from server randomly overwrites my fixes in this script.
It is difficult while solving some bugs to find out that the incorrect clock is set up by OpenOCD integrated into the IDE.

This stupid issue costs me many hours. I asked but AC6 is closed source code. I am ready to rebuild plug in in order for my changes to be always applied.

[matbob]

Hello ace1903,

Restarting the IDE did not overwrite the config file in my case, but definitely as you said an update will overwrite it.

One thing I did not understand is that the SystemClock_Config() function is called after the debugger programs the microcontroller and when we hit the "Resume" button. So, why the RCC is not getting configured correctly once the program starts executing?

Another work around I found is to hit the "Reset the chip and restart debug session" button when the debugger is halted at the HAL_Init() function at the beginning of debugging. Is there a way to do this automatically by issuing an OpenOCD/gdb command from the AC6 Debug Configuration setup?

[Yansi]

OpenOCD needs to initialize the flash controller in order to program the memory.
I am OK with that.

I thought we talked about connecting a debugger, not FLASH memory programming.

Debugger should always connect as much non-intrusively as possible, and modifying the clock tree is not certainly what it should do to a running target.

If it needs to write FLASH, then it should STOP execution, RESET, download the FLASHloader to SRAM and then run it from there.

[S. Petrukhin]

Why should a fucking  OpenOCD even touch these registers without the consent of the programmer?

If you program with checkboxes in CubeMX and use other people's tools, then do not be surprised by their glitches and clandestine actions. 

[ace1903]

In my case problem is/was that PLL shall not be re-programmed while the running system is clocked by that PLL.
I added to the script to turn off the PLL first and then program with my settings.

STM32CubeIDE assumes that code will be used on micro with all registers in reset condition.
That is why your workaround with reset the chip and restart debug session works.

I worked on OpenOCD code years ago. I agree that should be non-intrusive as possible.
Maybe those PLL settings are part of ST branch only, I am not sure.

I have experience with Lauterbach debuggers, expensive stuff but very powerful.
Most of the time I wrote my scripts that did all the flashing and each register access was strictly controlled.
There was mode to attach on running target with zero intrusion.

OpenOCD is quite capable also. But ST makes changes that make life easier for millions of Nucleo users.
Take Nucleo,  install CubeMX and in 5min you have blinking led or hello world application.
More advanced uses of ST micros like ours seem not to be the main focus.

All I need is a way to persuade  IDE to use only my scripts. 

 
     
 

[ace1903]

If you program with checkboxes in CubeMX and use other people's tools, then do not be surprised by their glitches and clandestine actions. 

Please do not poison this thread with how bad tools like CubeMX are.
Daily I use PIC16, PIC18, STM32F0, STM32F4, 8052 and CubeMX saves me a lot of headaches.
Back when I used only HC11 I knew each bit in each config register.
But over the years I used also OMAPs from Ti, imx6 from Freescale, and custom ASICs(data sheet ~4500pages).
Already have millions of pages from datasheets in my head. Simply no space left for subtle differences like clocking from HSE or HSI.

Writing code bit by bit in config registers for simple things like SPI driver is the last thing that I want to spend time on.
Let focus on how to improve existing tools.

[matbob]

In my case problem is/was that PLL shall not be re-programmed while the running system is clocked by that PLL.
I added to the script to turn off the PLL first and then program with my settings.
 

Thanks a lot. I digged into the SystemClock_Config() function and found that if the PLL is running already, no modifications to the PLL input clock, predivider and multiplication factor are done. Since the OpenOCD script already enabled the PLL, even though there is a call to the SystemClock_Config() function with PLL settings I desire, it does not come into effect. So the trick is to disable the PLL and use HSI clock after the HAL_Init() function. Then the call to the SystemClock_Config() function will set my desired clock configuration. The code will lokk like this:

Code: [Select]

  /* Reset of all peripherals, Initializes the Flash interface and the Systick. */
  HAL_Init();

  /* USER CODE BEGIN Init */
  //Disable PLL and switch to HSI (8 MHz), correct PLL setting will take place inside SystemClock_Config()
  if((RCC->CFGR & RCC_CFGR_SWS) == RCC_CFGR_SWS_PLL)
  {
  RCC->CFGR &= (uint32_t) (~RCC_CFGR_SW);
  while ((RCC->CFGR & RCC_CFGR_SWS) != RCC_CFGR_SWS_HSI);
  }
  /* USER CODE END Init */

  /* Configure the system clock */
  SystemClock_Config();


[S. Petrukhin]

If you program with checkboxes in CubeMX and use other people's tools, then do not be surprised by their glitches and clandestine actions. 

Please do not poison this thread with how bad tools like CubeMX are.
Daily I use PIC16, PIC18, STM32F0, STM32F4, 8052 and CubeMX saves me a lot of headaches.
Back when I used only HC11 I knew each bit in each config register.
But over the years I used also OMAPs from Ti, imx6 from Freescale, and custom ASICs(data sheet ~4500pages).
Already have millions of pages from datasheets in my head. Simply no space left for subtle differences like clocking from HSE or HSI.

Writing code bit by bit in config registers for simple things like SPI driver is the last thing that I want to spend time on.
Let focus on how to improve existing tools.

You can choose: spend time studying the datasheet or beat your head about software glitches.