Application runs very slow using the debugger

[roger239955_stm1]

Debugging via SWD using either STLink or JLinkEdu from STM32CubeIDE to a STM32F405, I've noticed the application runs around 16 times slower when its run in the debugger.

Also the USB (Virtual Com device) does not even appear on my host PC when the debugger is launched from inside STM32CubeIDE

To attempt to isolate the problem, I've tried a STLink as well as JLinkEdu and the result was the same.

If I run the JLinkGDBServerCLI using the command line cut and past from the Debug Configuations in STM32CubeIDE and separately run GDB (arm-none-eabi-gdb), the application runs at full speed, and the USB device works fine.

I've looked at the Debug configuation settings in STM32Cube, and tried changing various things e.g. Live Expressions, but this made no difference.

Can anyone advise how to resolve this problem.

[Piranha]

About the password thing...

https://community.st.com/s/question/0D53W00000Cg0McSAJ/strange-forum-password-policy

https://community.st.com/s/question/0D53W00000euAcUSAU/logins-broken-by-new-password-rules

As they say: "we're looking into it." For years... ;)

[mattias norlander]

Thinking about this again... What are the odds that both the JLINK and the ST-LINK (CubeProg) flash loader would suffer the same issue? I forgot about this factor. Not sure my hypothesis makes sense when considering same issue with JLINK. :\

... Still unable to re-produce on our side, so for now just passively following additional replies until we get some more clue.

I will ask the team responsible for flash loaders to review if the flash loader cleans up the interrupts properly. Please let us know if "disabling download" solves the issue 100% of the time or if you discover any other clue to this mystery.

ST internal ticket reference: 117095

[mattias norlander]

@roger239955_stm1​ ,

I had a colleague develop a flash loader file which does not use interrupt. It would be interesting to have you try this file and debug with download enabled just to verify if that solves the issue. I contact you by PM/e-mail.

[EHolm.5]

@roger239955_stm1​ I ran into the same problem when using the J-Link. STLink did not show this problem. Power cycling the board restored normal behavior, so it does seem like a clock tree setup, but I haven't had time to dig into it.

A work-around is to simply click on the "reset the chip and restart debug session" which works correctly.

 

Hope that helps anyone else running into this issue and maybe one of us will have some spare time to dig through the clock tree to see what is actually wrong.

-Eric

[roger239955_stm1]

@EHolm.5​ 

Thanks.

I already use the Restart trick.

[mattias norlander]

Hi @roger239955_stm1​, 

This discussion was re-visited internally...

Do you still face this problem?

Are you able to share with us your project, or a minimal project which re-produces the issue on an STM32 EVB?

[roger239955_stm1]

I don't know if this is still a problem, because I am no longer debugging the firmware using an external debugger.

However, I think I now know what causes the problem.

The STM32Cube code assumes the code is not started via a bootloader.

Because I was using a bootloader, which used the HSE clock, but with lower overall clock speed (72Mhz instead of the normal 168Mhz)

The STM32Cube generated code to set the PLL's don't work, becuase the code does not allow the HSE PLL to be changed when the clock source is HSE.

So I had to add some code into a User block, at the start of main.c, to change the clock input to HSI, just before the STM32Cube which configures the HSE and PLL etc.

This solved the problem with the PLL being incorrect configured and I think may also solve the problem when using STLink debugging.

I'm surprised no one encountered this problem before, because a lot of application firmware is loaded via a bootloader, so equipment can be updated via DFU

Perhaps people use a bootloader which uses the same clock speed as their main application

Probably the STM32Cube generated code should check whether the clock input is HSE

My code is

  /* Reset of all peripherals, Initializes the Flash interface and the Systick. */
  HAL_Init();
 
  /* USER CODE BEGIN Init */
  __HAL_RCC_SYSCLK_CONFIG(RCC_CFGR_SWS_HSI);//Switch clock to internal, as bootloader already set it to HSE and otherwise HSE can't be configured in SystemClock_Config()
  /* USER CODE END Init */
 
  /* Configure the system clock */
  SystemClock_Config();

[Tesla DeLorean]

>>Perhaps people use a bootloader which uses the same clock speed as their main application

Well it does mean you only need to go through the HSE startup and PLL to lock once. Similarly configuring external memory interfaces.

[roger239955_stm1]

In my experience bootloaders only normally configure the essentials for the firmware to be loaded, and don't configure any other interfaces e.g. Serial , I2C etc

I have seen some bootloaders which deliverately use HSI so that they are not reliant on the board having HSE at the desired frequency.

I'm not sure whether technically USB is supposed to work OK on HSI, but I have seen people use HSI with USB and claim they never had any problems.

Some other MCU's have USB clock recovery which can be used for the main clock, and I've seen bootloaders which use that recovered clock, even though the main application uses an external clock.

[EHolm.5]

I tracked the problem down to the application code configuring the PLL without first disabling it, so the changes were ignored.

Adding the + line fixed it and I could use any JTAG pod.

+	LL_RCC_PLL_Disable();
 	LL_RCC_PLL_ConfigDomain_SYS(LL_RCC_PLLSOURCE_HSE, LL_RCC_PLLM_DIV_1, 20, LL_RCC_PLLR_DIV_2);
 	LL_RCC_PLL_EnableDomain_SYS();
 	LL_RCC_PLL_Enable();