cancel
Showing results for 
Search instead for 
Did you mean: 

Remote debugging on STM32Cube IDE

Tbone1
Associate II

Hello,

I have a Nucleo L476RG development board which I would like to remotely debug from a local PC which is running windows 11.

I have connected the nucleo board to a linux machine (Ubuntu) and have started the ST-LINK_gdbserver application from /opt/st/stm32cubeide_1.7.0/plugins/com.st.stm32cube.ide.mcu.externaltools.stlink-gdb-server.linux64_2.0.0.202105311346/tools/bin/

After I run the application the terminal window shows the following information.

0693W00000JP0oWQAT.pngThe stm32Cube IDE is running on the local pc(windows) which is connected to the network. The debug configurations is configured as follows

0693W00000JP0m8QAD.pngWhen I try to debug the application the following screens appear

0693W00000JP0rzQAD.png0693W00000JP0snQAD.png 

Can you help me to solve this issue or can you provide me with a solution for remotely debuging the application from another PC on the local network?

1 ACCEPTED SOLUTION

Accepted Solutions
mattias norlander
ST Employee

We solved the issue by disabling the "Live expressions". For some reason the live data channel is timing out on this machine.

The lesson learned: Even if Live expression times out, it should not be allowed to kill the whole debug session. It should instead only warn that it suffered a timeout and that the feature will be unavailable.

Internal ticket reference: 123647

View solution in original post

7 REPLIES 7
Tbone1
Associate II

I have tried the same replacing the UBUNTU with an windows pc and running the ST-LINKservergdb.exe. Now I am able to debug the code. Does this bring any direction to the issue with the OS being used.

How can it be used on an Linux distribution?

mattias norlander
ST Employee

Hi,

We have not been able to reproduce the problem. GDB-server version 5.9.1 running on a Ubuntu machine and CubeIDE version 1.7.0 running on Windows.

Can you test the following:

  • Create a new debug configuration from scratch on the windows machine.
  • Change it to connect remotely.
  • Run it.

This is just to rule out any portability issues in case the debug settings moved between different platforms.

If still not working. Can you provide some more logging information:

  • Enable the option “Show the GDB traces console…�?. This option is found in CubeIDE menu: “Window->Preferences->C/C++>Debug->GDB�?
  • Open the “Console�? view
  • Click on “Display selected console�? in the “Console�? view toolbar.
  • Select “gdb traces�?

This console should output all communication between the IDE and the GDB-server. Can you provide the output?

Hi,

I have created a new debug configuration and tested ---> The issue was not resolved (I was not able to debug the MCU),

I have attached the debug log for your reference

mattias norlander
ST Employee

The connection seem to work well which contradicts the initial error dialog you received with Failed to execute MI command: target remote...

Can we do a screen share session? Drop me a PM and we can have a look...

JanssonSoftware
Associate II

Hi,

Just an idea. Might be related to network latency. Test to increase the "Remote timeout" setting. Available under:

"Window->Preferences->C/C++->Debug->GDB"

Default GDB timeout is 2s. Test to set it to 10s.

mattias norlander
ST Employee

We have now managed to reproduce this error message in cases when the network communication (server responses) is really slow.

In addition to the reply by @Community member​, you could also try to increase the debugger maximum connection time limit. Currently there is no UI option for this but a workaround is to add the attached two file to the project root folder. This will increase this time limit from 15s to 30s.

This might solve the problem but the interesting question is why its so slow in the first place?  

mattias norlander
ST Employee

We solved the issue by disabling the "Live expressions". For some reason the live data channel is timing out on this machine.

The lesson learned: Even if Live expression times out, it should not be allowed to kill the whole debug session. It should instead only warn that it suffered a timeout and that the feature will be unavailable.

Internal ticket reference: 123647