Getting live watch values in hex

[AHugh.2]

Quick question - how do I get STM32CUBE Live Watch to display values in hex? I have the output radix set to 16 so normal watch shows hex values but live watch is in decimal.

Latest preview versions of VSCode extensions (STLink GDB Server v0.10.1)

[Florent V]

Hi AHugh.2

Thanks for your feedback. Unfortunately, this is not possible with the current version of the STM32CUBE Live Watch view, but we have added this feature to our roadmap.

BR,
/Flo

[arthhh]

Hi @Florent V,

I’m trying to replicate in VS Code what I do in STM32CubeIDE: edit Live Expressions while the target keeps running and get a fast refresh rate.

Setup

• Probe: ST-LINK V3

• Backend: ST-LINK GDB Server

• IDE: VS Code 

      Identifier stmicroelectronics.stm32-vscode-extension
      Version 3.5.1

• MCU: STM32G431

• OS: Windows 11

What works in CubeIDE

• I can change variable values without halting.

• Live update rate is ~10–20 Hz (good enough for tuning).

What I see in VS Code

• Live Expressions appear read-only while running (I can edit only when halted).

• The update rate is slow (≈1–2 Hz) even with higher polling configured.

Launch snippet (VS Code)

"liveWatch": 
{ 
    "enabled": true, 
    "samplesPerSecond": 20, 
    "expressions": ["a", "b", "c"] 
}

Variables are volatile and not optimized out (-Og).

Questions

1. Does the STM32 VS Code extension + ST-LINK GDB Server support write-while-running for Live Expressions? If yes, how do I enable it (any specific setting for background memory write)?

2. How can I increase the refresh rate beyond ~1–2 Hz? Is samplesPerSecond the right knob, or is there another limit (probe, server, transport) I should tweak?

3. Are there known limitations vs. STM32CubeIDE in this area? Any roadmap item for parity?

Things I’ve tried

• Marked tunables as volatile; ensured they aren’t optimized away.

• Increased liveWatch.samplesPerSecond (10 → 20).

• Attempted memory writes via Debug Console while running (seems blocked).

• Verified ST-LINK V3 firmware is current.

If this isn’t supported yet, I’d appreciate guidance on the recommended workaround within the STM32 VS Code workflow (e.g., RTT/UART command channel) and any settings that can safely improve the polling rate.

Happy to attach logs, exact versions, and a minimal project if helpful.
Thanks!

[Florent V]

Hi arthhh,

Sorry for the late reply,
Thank you for the detailed information you provided.

1. Does the STM32 VS Code extension + ST-LINK GDB Server support write-while-running for Live Expressions? If yes, how do I enable it (any specific setting for background memory write)?

=> Currently not supported – similar to the native watch view – this feature has been added to the roadmap.

2. How can I increase the refresh rate beyond ~1–2 Hz? Is samplesPerSecond the right parameter, or is there another limit (probe, server, transport) I should tweak?

=> The refresh rate depends on the combination of samplesPerSecond and the GUI refresh rate.
The GUI refresh rate is hardcoded to 300 ms in our extension (which is a limitation on our side), so samplesPerSecond serves as the accuracy for the displayed values.
Based on tests, we cannot go below 200 ms, resulting in a maximum of 5-6 GUI updates per second (see attached video).
Due to this limitation, we currently achieve about 3-4 Hz (which differs from your tests).
We plan to propose an improvement by allowing the GUI refresh rate to be modified.

3. Are there known limitations compared to STM32CubeIDE in this area? Any roadmap items for parity?

=> Yes, there are differences compared to CubeIDE Eclipse, both in writing and refresh rate. Tickets have been created internally to investigate and address these.

Other point:

• Our liveWatch attribute does not support the sub-attribute expressions. Could you please clarify where this comes from on your side?

Kind regards,
Flo

[arthhh]

Hi, thanks for the quick follow-up!

About the liveWatch.expressions sub-attribute: that came from our launch.json where we tried to pre-seed a list of items for Live Watch e.g.

"liveWatch": 
{ 
    "enabled": true, 
    "samplesPerSecond": 20, 
    "expressions": ["kp", "ki", "kd"] 
}

If this sub-attribute isn’t supported, understood—please ignore it on your side. The intent was to convey a feature request: a way to persist/predefine Live Watch items from configuration.

Our use case (power electronics tuning):
When we’re debugging and running tests, we often can’t halt or restart a session. In STM32CubeIDE, we use Live Expressions to:

• Add computed expressions that aren’t calculated on the MCU, e.g.:

duty_pct = duty / 4095.0
p_in = vin * i_in
err = vref - vout

• Watch them update in real time, and edit variables while running (background memory write).

That lets us iterate on control parameters on the bench without instrumenting extra firmware code or stopping time-critical loops.

Best Regards,
Arthur