Loading...
 

Zephyr project on STM32

   Zephyr Workbench, a VSCode extension to manage Zephyr on STM32.
It enables users to easily create, develop, and debug Zephyr applications.
Main features:
  • Install host dependencies.
  • Import toolchain and SDK.
  • Create, configure, build and manage apps.
  • Debug STM32.
You can directly download it from the VSCode marketplace
For more details, visit the Zephyr Workbench

System Workbench for STM32

Forum List Topic List

[ prev topic ]  

Invalid thread id: 1

Posted by synaesthesia on 2017-09-12 08:51

Hi again,

I have been using System Workbench for STM32 for a while now without problems. Until recently when I updated Eclipse Neon. Since then the debugger didn’t work properly any more. So I created a fresh install of Eclipse Oxygen 4.7.0 and System Workbench for STM32. I can compile, flash the chip and start the debugger. Right after starting it stops at the first breakpoint and single-steps without a problem. However, when I set a second breakpoint, it will stop there and single-step does not work any more. I can resume, but the chip hangs. When I terminate the debug session, an error message is displayed:

Failed to execute MI command:
-stack -list -frames 0 0
Error message from debugger back end:
Invalid thread id: 1

Any help please?
(Win10, Eclipse Oxygen, bluepill board with F103C8, ST-LINK dongle, OpenOCD 1.16.0, OpenSTM32 IDE 2.2.0)

Edit: I noticed and fixed one issue on my side: the ST-LINK server wasn’t installed because I used the import method from within Eclipse. I installed the full package and the red warning message disappeared from the debug configuration panel. However, the problem still exists.

Reads: 8192
Link
Posted by HalCat on 2017-09-13 20:47

Hello.

I’ve also encountered something similar to the above mentioned problem when running the debugger with a known-to-work application.

Eclipse Version: Neon.3 Release (4.6.3) Build id: 20170314-1500
Target Board: STM32L496ZGT6 Nucleo-144 demo board.

When trying to enter into debugging mode via F11 the console window reports the following:
STM32L496ZGTx.cpu: target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x0800a034 msp: 0x20050000
STM32L496ZGTx.cpu: target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x0800a034 msp: 0x20050000
STM32L496ZGTx.cpu: target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x21000000 pc: 0x20000068 msp: 0x20050000
Warn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet not sent! (1845). Workaround: increase “set remotetimeout” in GDB
STM32L496ZGTx.cpu: target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x0800a034 msp: 0x20050000

Note: the “Warn” statement above is new.
After pressing F8, the application is NOT behaving correctly. If would appear that the time bases are incorrect.

Ending the debug session by pressing +F2 results in a dialog box popping open that states:
Failed to execute MI command:
--stack-list-frames 0 0
Error message from debugger back end:
Invalid thread id: 1

Perhaps there is something in common here with the OP.

Link

Posted by synaesthesia on 2017-09-13 23:12

Kept trying and got two more data points to isolate the issue: the problem only occurs for breakpoints that are placed in an interrupt handler. Breakpoints placed outside of an interrupt handler work fine. I can have as many as I want and the debugger single-steps and resumes fine.
In my case the breakpoint that causes the issue is in the SysTick_Handler. If the debugger stops in that handler, it either is dead immediately, or stops working after some steps. The pattern that I can observe is that it always happens on branch with link (BL) instruction. Not necessarily the very first one encountered, but after a few such instructions it does so for sure. No recursion in my code, maximum nesting is one level. The code worked before and the subroutines return via BX LR normally as long as the debugger is alive.
EDIT: exchanged the ST-LINK and the cable against known good ones - didn’t help

Link
Posted by synaesthesia on 2017-09-15 23:32

I completely reinstalled Eclipse and the OpenSTM32 plug-in. Build and flashing work fine. The code runs.
Then I set a breakpoint in my SysTick Handler a few instructions before what I identified as the critical point.
The first BL 0x8000f16 single-steps fine, but step-over jumps to 0800105e and the debugger stops working.
When I single-step through the first BL, the debugger stops working on the second BL 0x8000eb4 instruction.
There is plenty of stack space available (>4K). Memory looks good. No other interrupts enabled nor pending.
When I terminate the debugger, I always get the “Invalid thread id: 1” error message.

folding:
08001050: ldrb r1, [r5, #26]
08001052: bl 0x8000f16 — single-step ok, but step-over fails
filtering:
08001056: ldr r4, [r5, #12]
08001058: push {r5, r6}
0800105a: bl 0x8000eb4 — single-step and step-over fail
0800105e: pop {r5, r6}

Anybody with an idea what goes on here?

Link