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.

[roger239955_stm1]

I noticed this problem of slow running only occurs when the debugger is first started.

If I pause the application and the restart the application, it runs at the correct speed.

[ONadr.1]

I had the same problem with F401 and F103. I had to use other debug techniques when accurate timing was needed.

[mattias norlander]

Sounds quite weird.

Let me shoot some questions to narrow this down since this is nothing I can reproduce:

1. are these occurrences only on Windows or also Linux/Mac?
   1. If only on Windows then maybe we could imagine yet another problem with CDT starter.exe...
2. If you use ST-LINK with OpenOCD as "debug probe"? Same problem?
3. What if you change workspace and create a new default project. Still same issue?
   1. The answer could help us rule out metadata and launch configurations problems...
4. Do you know if this is isolated to CubeIDE 1.7.0 or have you seen the issue also in previous versions?
   1. This answer could give us clue whether only issue in specific Eclipse/CDT platform...

Any help to answer the questions above would be appreciated.

Since the issue is solved by launching the GDB-server externally, and the VCOM is not working either, and assuming this only happens on Windows - to be confirmed by you guys, the starter.exe theory is valid.

[roger239955_stm1]

Thanks for the reply.

In answer to your quesions

1. I'm using Windows 10. I may be able to test on Linux if this helps isolate the problem.
2. I use STLink directly from STM32CubeIDE. I'm not using OpenOCD. I'm not sure how to use OpenOCD, it seems like another unnecessary level of complication.
3. I made a new Workspace, imported the project, created a new Debug launch configuration and the same problem occurs
4. I've not used any other version of STM32Cube, than the current version.

The problem can be solved, by pressing the Suspend button, so the debugger halts the execution, and then pressing the button which "Resets the chip and restart debug session"

Here is the log from my console, including suspending and restarting.

Note. If I hit the stop button and then debug again from the beginning, the IDE or debugger seems to read and verify that the ROM does not need to be updated, and it then starts the application to debug it. The problem still occurs. ie Its not associated with the flashing of the application to the ROM, the problem occurs even if new new application is flashed.

---------------------- Console log ----------------------------------------------

SEGGER J-Link GDB Server V7.22a Command Line Version

JLinkARM.dll V7.22a (DLL compiled Jun 9 2021 16:33:57)

Command line: -port 2331 -s -device STM32F405VG -endian little -speed 12000 -if swd -vd

-----GDB Server start settings-----

GDBInit file:                 none

GDB Server Listening port:    2331

SWO raw output listening port: 2332

Terminal I/O port:            2333

Accept remote connection:     localhost only

Generate logfile:             off

Verify download:              on

Init regs on start:           off

Silent mode:                  off

Single run mode:              on

Target connection timeout:    0 ms

------J-Link related settings------

J-Link Host interface:        USB

J-Link script:                none

J-Link settings file:         none

------Target related settings------

Target device:                STM32F405VG

Target interface:             SWD

Target interface speed:       12000kHz

Target endian:                little

Connecting to J-Link...

J-Link is connected.

Firmware: J-Link EDU Mini V1 compiled Jun 7 2021 15:44:25

Hardware: V1.00

S/N: 801010752

Feature(s): FlashBP, GDB

Checking target voltage...

Target voltage: 3.29 V

Listening on TCP/IP port 2331

Connecting to target...

Connected to target

Waiting for GDB connection...Connected to 127.0.0.1

Reading all registers

Read 4 bytes @ address 0x08017478 (Data = 0x681B4B06)

Read 2 bytes @ address 0x08017478 (Data = 0x4B06)

Connected to 127.0.0.1

Reading all registers

Read 4 bytes @ address 0x08017478 (Data = 0x681B4B06)

Reading 64 bytes @ address 0x20008600

Read 4 bytes @ address 0x080180E0 (Data = 0xB085B480)

Received monitor command: WriteDP 0x2 0xF0

O.K.

Received monitor command: ReadAP 0x2

O.K.:0xE00FF003

Reading 32 bytes @ address 0xE00FFFD0

Received monitor command: reset

Resetting target

Downloading 392 bytes @ address 0x0800C000 - Verified OK

Downloading 16048 bytes @ address 0x0800C190 - Verified OK

Downloading 16080 bytes @ address 0x08010040 - Verified OK

Downloading 16096 bytes @ address 0x08013F10 - Verified OK

Downloading 16128 bytes @ address 0x08017DF0 - Verified OK

Downloading 16032 bytes @ address 0x0801BCF0 - Verified OK

Downloading 16096 bytes @ address 0x0801FB90 - Verified OK

Downloading 16080 bytes @ address 0x08023A70 - Verified OK

Downloading 15952 bytes @ address 0x08027940 - Verified OK

Downloading 16048 bytes @ address 0x0802B790 - Verified OK

Downloading 15952 bytes @ address 0x0802F640 - Verified OK

Downloading 16112 bytes @ address 0x08033490 - Verified OK

Downloading 16112 bytes @ address 0x08037380 - Verified OK

Downloading 16096 bytes @ address 0x0803B270 - Verified OK

Downloading 16032 bytes @ address 0x0803F150 - Verified OK

Downloading 16128 bytes @ address 0x08042FF0 - Verified OK

Downloading 15968 bytes @ address 0x08046EF0 - Verified OK

Downloading 11600 bytes @ address 0x0804AD50 - Verified OK

Downloading 16336 bytes @ address 0x0804DAA0 - Verified OK

Downloading 16272 bytes @ address 0x08051A70 - Verified OK

Downloading 16272 bytes @ address 0x08055A00 - Verified OK

Downloading 16240 bytes @ address 0x08059990 - Verified OK

Downloading 2736 bytes @ address 0x0805D900 - Verified OK

Downloading 8 bytes @ address 0x0805E3B0 - Verified OK

Downloading 4 bytes @ address 0x0805E3B8 - Verified OK

Downloading 4 bytes @ address 0x0805E3BC - Verified OK

Downloading 16352 bytes @ address 0x0805E3C0 - Verified OK

Downloading 16352 bytes @ address 0x080623A0 - Verified OK

Downloading 876 bytes @ address 0x08066380 - Verified OK

Writing register (PC = 0x 800defc)

Read 4 bytes @ address 0x0800DEFC (Data = 0xD034F8DF)

Read 2 bytes @ address 0x0800DEFC (Data = 0xF8DF)

Read 2 bytes @ address 0x0800DEFE (Data = 0xD034)

Reading 64 bytes @ address 0x08027380

Read 2 bytes @ address 0x080273F0 (Data = 0x4B9D)

Read 4 bytes @ address 0xE000ED14 (Data = 0x00000200)

Downloading 4 bytes @ address 0xE000ED14 - Verified OK

Reading all registers

Read 4 bytes @ address 0x0800DEFC (Data = 0xD034F8DF)

Read 2 bytes @ address 0x0800DEFC (Data = 0xF8DF)

Read 2 bytes @ address 0x0800DEFE (Data = 0xD034)

Read 4 bytes @ address 0xE000EDFC (Data = 0x01000000)

Downloading 4 bytes @ address 0xE000EDFC - Verified OK

Reading all registers

Read 4 bytes @ address 0x0800DEFC (Data = 0xD034F8DF)

Read 2 bytes @ address 0x0800DEFC (Data = 0xF8DF)

Read 2 bytes @ address 0x0800DEFE (Data = 0xD034)

Starting target CPU...

Debugger requested to halt target...

...Target halted (PC = 0x0800E2D6)

Reading all registers

Read 4 bytes @ address 0x0800E2D6 (Data = 0x3FFFF1B3)

Reading 64 bytes @ address 0x2000B040

Read 4 bytes @ address 0x080272A4 (Data = 0x2B004603)

Read 4 bytes @ address 0x0802731E (Data = 0x2B004603)

Read 4 bytes @ address 0x08027426 (Data = 0x73FB4603)

Reading 64 bytes @ address 0x2000B080

Read 4 bytes @ address 0x0800D736 (Data = 0x2B006B3B)

Reading 64 bytes @ address 0x2000B100

Read 4 bytes @ address 0x080180E0 (Data = 0xB085B480)

Read 4 bytes @ address 0x080180E0 (Data = 0xB085B480)

Received monitor command: reset

Resetting target

Read 4 bytes @ address 0xE000ED14 (Data = 0x00000200)

Downloading 4 bytes @ address 0xE000ED14 - Verified OK

Reading all registers

Read 4 bytes @ address 0x080054F8 (Data = 0x47804801)

Read 2 bytes @ address 0x080054F8 (Data = 0x4801)

Read 4 bytes @ address 0xFFFFFFFE (Data = 0x09300000)

Read 2 bytes @ address 0xFFFFFFFE (Data = 0x0000)

Read 4 bytes @ address 0xFFFFFFFE (Data = 0x09300000)

Read 2 bytes @ address 0xFFFFFFFE (Data = 0x0000)

Read 4 bytes @ address 0xE000EDFC (Data = 0x01000000)

Downloading 4 bytes @ address 0xE000EDFC - Verified OK

Reading all registers

Read 4 bytes @ address 0x080054F8 (Data = 0x47804801)

Read 2 bytes @ address 0x080054F8 (Data = 0x4801)

Starting target CPU...

[roger239955_stm1]

How slow did your application run.

I didn't initially notice it was running around 16 time to slow, until the I realised the keyboard handler didn't work correctly, as it detects any press longer than half a second as a "Long" press and the application should respond accordingly.

But I had to hold buttons down for around 10 seconds to get the Long Press functions to work

[roger239955_stm1]

BTW. I tried different speeds. 4000kHz and 12kHz both behave the same

[ONadr.1]

I notice, when I try to measure how long the procedure takes. I got tick on the entry point and at the end of procedure, subtracted this ticks and place the breakpoint for reading the value. I was surprice, how many miliseconds procedure lasted. So i printed out the value through serial port in debug and normal mode. It was much more slower in debug mode. I dont remember acurate ratio, but it could be cca ten times. I considered it normal and I use different method for time senzitive debuging.

[mattias norlander]

Had some internal discussions...

Could you have a look at the configuration of the clock tree in your embedded application?

Maybe the CPU is running 16x slower because the configuration of the clock tree fails in "Debug". Then after a proper reset it runs at normal speed. Which reset modes are you using? Maybe when you use JLinkGDBServerCLI externally another reset mode is applied. I encourage you to experiment with reset modes and to analyze the clock tree status registers once your application is running "slow".

Please share your findings so that we know if we have a tool bug, or if this is application code issues.

[roger239955_stm1]

void SystemClock_Config(void)

{

 RCC_OscInitTypeDef RCC_OscInitStruct = {0};

 RCC_ClkInitTypeDef RCC_ClkInitStruct = {0};

 /** Configure the main internal regulator output voltage

 */

 __HAL_RCC_PWR_CLK_ENABLE();

 __HAL_PWR_VOLTAGESCALING_CONFIG(PWR_REGULATOR_VOLTAGE_SCALE1);

 /** Initializes the RCC Oscillators according to the specified parameters

 * in the RCC_OscInitTypeDef structure.

 */

 RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSE;

 RCC_OscInitStruct.HSEState = RCC_HSE_BYPASS;

 RCC_OscInitStruct.PLL.PLLState = RCC_PLL_ON;

 RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSE;

 RCC_OscInitStruct.PLL.PLLM = 4;

 RCC_OscInitStruct.PLL.PLLN = 168;

 RCC_OscInitStruct.PLL.PLLP = RCC_PLLP_DIV2;

 RCC_OscInitStruct.PLL.PLLQ = 7;

 if (HAL_RCC_OscConfig(&RCC_OscInitStruct) != HAL_OK)

 {

   Error_Handler();

 }

 /** Initializes the CPU, AHB and APB buses clocks

 */

 RCC_ClkInitStruct.ClockType = RCC_CLOCKTYPE_HCLK|RCC_CLOCKTYPE_SYSCLK

                             |RCC_CLOCKTYPE_PCLK1|RCC_CLOCKTYPE_PCLK2;

 RCC_ClkInitStruct.SYSCLKSource = RCC_SYSCLKSOURCE_PLLCLK;

 RCC_ClkInitStruct.AHBCLKDivider = RCC_SYSCLK_DIV1;

 RCC_ClkInitStruct.APB1CLKDivider = RCC_HCLK_DIV4;

 RCC_ClkInitStruct.APB2CLKDivider = RCC_HCLK_DIV2;

 if (HAL_RCC_ClockConfig(&RCC_ClkInitStruct, FLASH_LATENCY_5) != HAL_OK)

 {

   Error_Handler();

 }

}

External clock source is 8MHz

The application does run in the debugger. The problem only exist after the initial launch.