cancel
Showing results for 
Search instead for 
Did you mean: 

LiveWatch causes breakpoints to still be active after debugger stops

NSAUG.1
Associate III

Hello,

 

In my STM32WBA65 + FreeRTOS project that I work on in VSCode, with the STM32CubeIDE for VScode extension, I came accross a rather strange and annoying behaviour:

It seems that when we enable liveWatch in our debug configuation in .vscode/launch.json, the breakpoints are still active after the debug session ends.

 

My minimal debug configuration:

{
      "type": "stlinkgdbtarget",
      "request": "launch",
      "name": "Build+Prog+Debug",
      "origin": "snippet",
      "cwd": "${workspaceFolder}",
      "preBuild": "${command:st-stm32-ide-debug-launch.build}",
      "imagesAndSymbols": [
        {
          "imageFileName": "${command:st-stm32-ide-debug-launch.get-projects-binary-from-context1}"
        }
      ],
      "liveWatch": {
        "enabled": true,
        "samplesPerSecond": "4"
      },
    }

 

I have the same behaviour with a hot-attach debug configuration if it has liveWatch enabled.

Here is how I test:

In one thread, I have code that reacts to two external stimuli lets call them S1 and S2 (in my case it's characters sent to the target on the serial), and two paths depending on the stimuli. Each stimuli triggers a visible response R1 and R2 (prints on the serial for me). I add a breakpoint to the code handling S2, just before it produces R2.

I also have another thread that blinks an led to act as a heartbeat of the RTOS.

I run the firmware on the target using either the launch configuration above, or the same without livewatch.

When the debugger is running, all behaves as expected in both configuration: S1 triggers R1, S2 triggers the breakpoint then after execution resumes, shows R2.

The behaviour changes after I stop the debug session (shift F5):

 

WITHOUT LiveWatch: 

The behaviour is as expected without a debugger running : S1 triggers R1, S2 triggers R2, the breakpoint never triggers (execution continues after R2). The heartbeat LED is never interrupted.

 

WITH LiveWatch:

S1 still triggers R1 normally.
S2 stops execution on the whole target (I suppose that it hits the breakpoint). There is no further response to stimuli, no heartbeat LED blinking.

At this point the target is stopped but the STLink still functions : I can start a normal prog+debug session, and things will just work normally.

However, trying to hot-attach the debugger at this point is unsucessful and just ends-up putting the STLINK in a state it cannot recover from without unplugging it.

 

 

This leads me to think there is a problem with enabling liveWatch that causes the debugging session not to be properly terminated, or the hardware not being aware of it in any case.

 

So for now I'll just refain from using liveWatch.

 

2 REPLIES 2
Nawres GHARBI
ST Employee

Hi @NSAUG.1 

could you please share a minimal project showing this issue, it will be helpful for debug 

NSAUG.1
Associate III

Hello,

Using slightly modified demo code for the Nucleo-WBA65RI generated by STM32CubeMX (the interrupt handling of the buttons does not work in that generated code, BTW), and here is a simple demo for the problem:

Each of the 3 user buttons changes the LEDs to a different color.

I added 3 debug configurations, a normal one without liveview (build+prog+debug) and the same with liveview. The third is a hot-attach debug, with liveview.

 

- Open the project in VScode and add a breakpoint in main.c: l.165 (where indicated):

/* Infinite loop */
  /* USER CODE BEGIN WHILE */
  while (1)
  {    
    check_buttons();
    if (leds_need_update == 1)
    {
      leds_need_update = 0;
      if (use_led == 0)
      {
        BSP_LED_On(LED_BLUE);
        BSP_LED_Off(LED_GREEN);
        BSP_LED_Off(LED_RED);
      }
      else if (use_led == 1)
      {
        BSP_LED_Off(LED_BLUE);
        BSP_LED_On(LED_GREEN);
        BSP_LED_Off(LED_RED);
      }
      else if (use_led == 2)
      {
        BSP_LED_Off(LED_BLUE);
        BSP_LED_Off(LED_GREEN);
        BSP_LED_On(LED_RED); // PUT YOUR BREAKPOINT HERE : with liveview and debugger started then stopped, it will stop here with no led ON (which it should not, and does not when debugging without liveview then closing the debugger).
      }
    }

    HAL_Delay(10);
  }
  /* USER CODE END 3 */

 

- Start debugging (with or without liveview) :

  • 3 leds start all ON
  • buttons B1 and B2 change the leds colors, and B3 triggers the breakpoint after turning all leds off. If we resume execution, the leds show red.

 

- then stop the debugging session:

  • if you were running without liveview, each button still changes the leds color normaly.
  • if you were running with liveview, pressing B1 and B2 still work normally, but pressing B3 turns all leds off, and from there you have to reset the board to regain functionality.
    If you then run the third debug configuration "Hot-attach with livewiew", it will often start and show that the execution is stopped at the breakpoint, but also often just fail to connect to ST-LINK requiring unplugging/re-plugging to regain functionality.

 

Cheers