2021-10-08 02:50 AM
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.
Solved! Go to Solution.
2021-10-28 04:26 AM
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.
2021-10-08 03:00 AM
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.
2021-10-08 03:51 AM
I had the same problem with F401 and F103. I had to use other debug techniques when accurate timing was needed.
2021-10-08 05:01 AM
Sounds quite weird.
Let me shoot some questions to narrow this down since this is nothing I can reproduce:
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.
2021-10-09 12:13 AM
Thanks for the reply.
In answer to your quesions
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...
2021-10-09 12:16 AM
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
2021-10-09 12:16 AM
BTW. I tried different speeds. 4000kHz and 12kHz both behave the same
2021-10-11 12:47 AM
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.
2021-10-11 01:29 AM
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.
2021-10-11 01:59 AM
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.