Just a hint:
I’m trying to debug a very simple hello world WisBlock app:
using PlatformIO debugger with Segger JLink EDU module, the PIO default JLinkGDBServer, connecting to the WisBlock SWD interface.
PIO starts the debug process, the debugger stops in main() as expected. If I then hit “continue” more times than not the app will crash giving me the the following stack trace:
??@0x00000a64 (Unknown Source:0)
signal handler called>@0xfffffff1 (Unknown Source:0)
??@0x00000aca (Unknown Source:0)
signal handler called>@0xfffffff9 (Unknown Source:0)
vPortStartFirstTask@0x0002a3be
xPortStartScheduler@0x0002a102
??@0x00000000 (Unknown Source:0)
I did have “some” success if I single stepped thought the initialization code rather than run full speed.
After much searching I ran across a PlatformIO forum post that took me in the correct direction. See link below.
The post talks about creating a gdb startup function, but I found it’s just as easy to:
- start the debug process, then when the debugger stops in main(), it’s default behavior.
- set your break point in your app code if you wish
- in the PIO “Debug Console” view enter
restart
PIO will then restart the debugging but will “not” stop at main() again, thus the need to set the break point before the restart, if needed.
STLink was not explicitly giving me this problem but I believe it’s because STLink would not stop at the initial main() break point, rather it hung/spun somewhere (don’t know where my STLinks are now toast) forcing me to hit the debugger restart button. Perhaps effectively doing what the above restart procedure is doing with JLink.
The PlatformIO forum link if interested: https://community.platformio.org/t/hang-starting-nrf52840-feather-express-under-segger-debugger/12181/11.