RTOS Proxy (ThreadX Cortex-M7) disconnects during flash when using J-Link GDB

[bbee]

I am experiencing a problem with RTOS Proxy in STM32CubeIDE 2.0.0/2.1.0 when debugging a ThreadX application on STM32H753 using a SEGGER J-Link.

The same setup works correctly with STM32CubeIDE 1.19.0, but after upgrading to 2.0.0/2.1.0 the debugger aborts during the flash download when RTOS Proxy is enabled. If I use J-Link Kernel Awareness instead RTOS Proxy everything works fine.

Configuration

• MCU: STM32H753BI

• RTOS: ThreadX

• STM32CubeIDE: 2.0.0

• RTOS Proxy: ThreadX / Cortex-M7

• Debug probe: SEGGER J-Link Ultra+

• J-Link GDB Server: V8.80

• Interface: SWD

Debug configuration:

• RTOS Awareness: Enabled
• RTOS Kernel Awareness: RTOS Proxy
• RTOS: ThreadX (Cortex-M7)

Problem

When starting a debug session, the debugger stops at the point where the firmware should be downloaded.

The following error appears:

Remote communication error. Target disconnected: Not a directory.
Failed to execute MI command:
load <path>/app_1500_xg.elf

where <path> is the correct and full absolute path to my elf file.
After the abort, only 664 bytes are written to flash.

RTOS Proxy log

STMicroelectronics RTOS Proxy. Version 0.17.0

Loading RTOS driver... ThreadX
ThreadX, port driver created: cortex_m7
Port driver loaded: cortex_m7

Connecting to GDB server 127.0.0.1 on port 2331 ... Connected
Listen for GDB connection on port: 60000 ... Connected

_tx_thread_current_ptr:0x2403cfa4
_tx_thread_created_ptr:0x2403cfac
_tx_thread_system_state:0x240005a0
_tx_semaphore_created_ptr:0x2403cf70
_tx_mutex_created_ptr:0x2403cf88
_tx_timer_created_ptr:0x2403d0e4
_tx_queue_created_ptr:0x2403cf78
_tx_event_flags_created_ptr:0x2403cf80
_tx_block_pool_created_ptr:0x2403cf90
_tx_byte_pool_created_ptr:0x2403cf98

Lost connection to GDB Client
Proxy stopped.

J-Link GDB server log (excerpt)

SEGGER J-Link GDB Server V8.80
Downloading 664 bytes @ address 0x08000000 - Verified OK
GDB closed TCP/IP connection

It looks like the RTOS Proxy terminates the GDB connection during the load command.

Additional observations

• If I disable RTOS Awareness, the firmware downloads correctly and debugging works.

• If I select RTOS Kernel Awareness: J-Link instead of RTOS Proxy, everything works correctly and ThreadX threads are displayed.

• The issue only appears when RTOS Proxy is enabled.

Question

Is RTOS Proxy currently supported with the SEGGER J-Link GDB server in STM32CubeIDE 2.0.0/2.1.0, or is this a known issue?

Has anyone successfully used RTOS Proxy with ThreadX + Cortex-M7 + J-Link in CubeIDE > = 2.0.0?

Any hints or workarounds would be appreciated.

Thank you.

[Ghofrane GSOURI]

Hello @bbee 

A ticket  225371   has already been escalated to dev team to address this behavior.

I will keep you posted with updates.

THX

Ghofrane

 

[Andrew Neil]

---

@bbee wrote:

using a SEGGER J-Link.

---

Does it work with an ST-Link ?

There's been a number of threads lately reporting problems with J-Link and CubeIDE v2.1.0, where ST-Link works OK...

[Andrew Neil]

---

@Andrew Neil wrote:

---

There's been a number of threads lately reporting problems with J-Link and CubeIDE v2.1.0, where ST-Link works OK...

---

@bbee  There was a new CubeIDE release yesterday which addresses at least one J-Link issue:

STM32CubeIDE 2.1.1 released

[bbee]

I don't have a ST-Link yet, but I've ordered one...

[bbee]

Still waiting for the ST-Link, however I've tried it with STM32CubeIDE 2.1.1 and it is still the same behaviour.

[bbee]

Still no success and still waiting for the st-link.
In the meantime I've Iogged the communication between GDB client > RTOS Proxy (Port 60000) > GDB Server (Port 2331) and found:

• Connection was established, but programming stopped after 664 bytes

• Wireshark showed that a large GDB X packet (~64 KB) was sent

• Immediately after receiving this packet, the connection on port 60000 (RTOSProxy) was reset (TCP RST)

Measures Taken

To resolve the download issue:

• Limited the GDB packet size by adding the following command in the debugger startup configuration like:

   

  set remote memory-write-packet-size 1024

• After this change, the firmware download works reliably again

New Problem (RTOS Awareness)

After fixing the download issue, RTOS awareness is not working correctly:

• The debugger shows only one thread

• The RTOSProxy outputs repeatedly:

Kernel is running: true
Update threads. Failed collecting threads.

Observations

• RTOSProxy correctly resolves all required ThreadX symbols at startup, e.g.:

  _tx_thread_current_ptr
  _tx_thread_created_ptr
  _tx_thread_system_state
  ...

• These variables can also be read correctly in the debugger expression window, so memory access and symbols seem to be correct

• Important: In the CubeIDE view “ThreadX Thread List”, all tasks are displayed correctly

• This indicates:

  • The RTOS is running correctly

  • Thread structures are valid

  • The issue is specific to RTOSProxy thread collection

Additional Debugging

To get more insight, I enabled verbose logging for RTOSProxy:

• Added the following custom parameter in the launch configuration:

  --loglevel 15
  e.g.
  <stringAttribute key="com.st.stm32cube.ide.mcu.rtosproxy.rtosProxyCustomProperties" value="--loglevel 15"/>
  

Additional Context

• All Threads are created dynamically after the kernel has started

• The RTOS is running normally

• The application behaves as expected

 

 

[bbee]

I have finally received the ST-Link. Flashing the application now works without initialization commands , but the threads are still not displayed.
It shows the same behavior as with the ST-Link Debug Probe. Debugging itself works, however when the program is halted, the RTOS proxy console reports the error:
“Update threads. Failed collecting threads.”