Hello @jaredwolff ,
I thought some here might be interested to hear a discovery I made regarding JLInk and remote debugging of Zephyr based applications. Reading through the messages generated when invoking west -v debug in an nRF9160 + Zephyr + ncs_v1.6.1 app I was able to extract the following two command line calls:
JLinkGDBServer -select usb -port 2331 -if swd -speed 4000 -device cortex-m33 -silent -singlerun -nogui -rtos /opt/SEGGER/JLink_V760g/GDBServer/RTOSPlugin_Zephyr
and
/opt/gcc-arm-none-eabi-10.3-2021.10/bin/arm-none-eabi-gdb /home/ted/projects/zephyr-based/aws-iot-stand-alone/build/zephyr/zephyr.elf -ex 'target remote :2331' -ex 'monitor halt' -ex 'monitor reset' -ex load
When I run the first command in one terminal window, I see a typical successful start up of gdb server, ending with a message about “Connecting . . .”. In a second Linux terminal I can then invoke the second command, and this brings me to a full remote debugging session with the app running on a Sparkfun Thing Plus nRF9160 (or similar nRF9160 based) board.
At this time I am still not seeing my expected listing of app threads, when at gdb’s prompt I issue thread apply all bt. The fact however that I now have insight into all the options passed to both the gdb server and gdb client, I am more confident that the server is running with the Zephry RTOS plug-in from Segger.
My more refined question now is: when connected to and debugging a remote Zephyr application in gdb, what command steps are needed to put the remote application in a state where gdb correctly shows Zephyr and the app’s threads?
One thing I observe is that as gdb start up it halts the firmware app. I can reset the firmware’s processor and restart it with the two gdb commands:
(gdb) monitor reset
(gdb) monitor go
I’ve even been able to “pause” the Zephyr app by alternately issuing via gdb it’s mon halt, mon go commands. But whether halted or running, gdb reports only the threads:
(gdb) thread find a
Thread 1 has target id 'Thread 57005'
Thread 2 has target id 'Remote target'
whereas Zephyr’s thread analyzer API reports from the firmware itself:
1) 'at_cmd_socket_thread' stack size 1472 bytes, stack used 432 bytes, 29%
2) 'thread_simple_cli' stack size 4096 bytes, stack used 1768 bytes, 43%
3) 'time_thread' stack size 1024 bytes, stack used 240 bytes, 23%
4) 'sysworkq' stack size 2048 bytes, stack used 168 bytes, 8%
5) 'idle 00' stack size 320 bytes, stack used 56 bytes, 17%
Am I misunderstanding how gdb is able to interact with, or supposed to interact with a multi-threaded application?
