Espruino Advanced Debug - Anyone have the missing jigsaw puzzle piece?

Sat 2021.10.02

Re-read

https://www.espruino.com/AdvancedDebug
https://github.com/espruino/Espruino/blob/master/README_BuildProcess.md

While I'm able to flash both a release and a debug .hex version built from VSCode using nRFConnect, and am able to build and debug the Nordic blinky and blinky_pwm examples using SEGGER embedded studio, I'm not able to understand (yet) the basic process I need to debug a running Espruino snippet.

I see and can navigate the Espruino .c source within VSCode. I am able to see the SEGGER blinky main.c example but not up to speed on where the background (SDK?) files are just yet, and can place breakpoints within SES and single step debug.

What jigsaw piece conceptually am I missing to somehow use either tool to configure the environment to step through from the WebIDE JS command down to the .c source that activates the hardware?

The key is the elf file, that one contains both the binary and symbols and links to source code files. Never used SES but quick googling gave this https://forum.segger.com/index.php/Thread/3487-Debug-elf-built-by-external-gcc-toolchain/

BTW it is not possible to single step nrf52 code once bluetooth is running, the softdevice has strict timing requirements so you cannot pause such code and continue, you can have breakpoint to investigate single issue but then you need to reboot.

However if you run NRF.sleep() to disable bluetooth before attaching debugger or remove BLUETOOTH module from build it should work.

In windows with WSL (1 not 2) I am using openocd build for windows to attach to the device via any of stlink/cmsis-dap/jlink usb dongles and then use gdb from linux command line e.g. arm-none-eabi-gdb espruino_2v10.83_E104BT5032A.elf -ex "target remote :3333" when run like this it will stop the code and I can investigate the state (backtrace, frame info, print, ...)
I can also open another connection to openocd from another command window (telnet localhost 4444) and use mix of openocd and gdb commands concurrently - openocd can read/write memory while the program is running and can restart the running program reset run without gdb noticing.

I guess VSCode with wsl integration could possibly debug the source via arm-none-eabi-gdb too but never tried this.

Sun 2021.10.03

Thank you @fanoush for the quick reply. Now have the rest of the weekend to maneuver the last of the jigsaw puzzle pieces.