Associate III

Solved

Application runs very slow using the debugger

Forum|Forum|4 years ago
October 8, 2021
5 replies
9619 views

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.

This topic has been closed for replies.

Best answer by mattias norlander

Could you make another more simple test instead.

In the debug configuration > Startup > Load Image and Symbols

Disable the Download of the binary. Unplug the board, re-plug it and launch debug without re-flashing the application.

Does it work better now? One hypothesis is that the flash loader shipped with CubeProgrammer puts the application in an unanticipated state. We have seen some other weird debug behaviours which could have this root-cause. So, please try and let us know if this could be the root-cause.

roger239955_stm1Author

Associate III

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.

mattias norlander

ST Employee

Sounds quite weird.

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

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...
If you use ST-LINK with OpenOCD as "debug probe"? Same problem?
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...
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_stm1Author

Associate III

Thanks for the reply.

In answer to your quesions

I'm using Windows 10. I may be able to test on Linux if this helps isolate the problem.
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.
I made a new Workspace, imported the project, created a new Debug launch configuration and the same problem occurs
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)

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...

ONadr.1

Senior III

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

roger239955_stm1Author

Associate III

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

ONadr.1

Senior III

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

ST Employee

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_stm1Author

Associate III

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.

roger239955_stm1Author

Associate III

@mattias norlander

Was this the information you needed ?

roger239955_stm1Author

Associate III

OK.

I'll need to make a new project from scratch.

However, one problem is always making a valid clock configuration.

Setting the external clock frequency and then running the automatic configuation never seems to result in the clocks being set to full speed.

The only way I found to get the automatic configuation to get full speed clocks, is to set one of the primary dividers so that the core clock is far too high, and then the automatic clock configurator seems to try various combinations of dividers and multipliers until a vaid set of clock paramaters is found.

And even then, this doesn't always seem to work.

I looked through all the HAL examples that the STM32CubeIDE can download and use as the base for a project, but I could not see a STM32F4 example of any kind which used the .ioc config file.

All the newer examples for the 7 Series etc had .ioc based projects but the F4 ones don't seem to have been updated

If there an example F4 project I could use, this would rules out all the other unknowns, because if I create a new project from scratch the clock config could still be miss-generated by the config tool

mattias norlander

ST Employee

The STM32F4 is not a new product series, consequently the STM32CubeF4 is in maintenance mode. No plan (to my knowledge) to add any example projects with ioc-files.

You could try to play with different clock sources to see if you can re-produce the "debug slow-down" only with some clock sources/configurations while not with other. I am afraid that this is a tricky issue to help out with, since we are unable to re-produce...

EHolm.5

Visitor II

@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_stm1Author

Associate III

@EHolm.5

Thanks.

I already use the Restart trick.

mattias norlander

ST Employee

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?

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded