Hello Devzone Community,
I am developing an nRF9160 based firmware for a battery powered device, and am attempting to examine the firmware using `gdb` at the command line. I have a JLink debugger from Segger as my physical debugging and programming device. I have Segger's JLink utilities installed on an Ubuntu 20.04 LTS host. The JLinkGDBServer version is 7.60.
My firmware is based on Nordic Semi ncs v1.6.1, and also has some basis yet specifically on Nordic's sample app `aws_iot`. While the aws_iot sample app is not designed to automatically enter nRF9160's lowest power modes for a particular time period, my understanding is that all the low power modes and features of the nRF9160 are achievable with proper amendments in firmware to this sample app.
My present goal is to see a complete listing of Zephyr RTOS and application (my specific app code) threads in a remote gdb debugging session. I'm able to start Segger's JLinkGDBServer and the GNU cross debugger at the command line, and interact some with my nRF9160 + Zephyr firmware. I also have Zephyr's thread analyzer module enabled in my project Kconfig settings in file prj.conf. But I get a disagreement between the threads that Zephyr RTOS 2.6.0 reports and what threads gdb with Segger's Zephyr RTOS plugin sees.
Excerpt 1 - Zephyr thread analyzer reported threads:
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%
Excerpt 2 - gdb reported threads:
(gdb) thread find [a-z0-9] Thread 1 has target id 'Thread 57005' Thread 2 has target id 'Remote target'
At gdb's prompt I have also tried the command which is mentioned in this Memfault dot com gdb tutorial. There's a lot of gdb I have yet to learn, but the following command appears to be a shorthand way to request a backtrace of all threads in the remote application.
Excerpt 3 - gdb command to show backtrace of threads:
(gdb) thread apply all bt [New Remote target] Thread 2 (Remote target): #0 z_arm_reset () at /home/ted/projects/zephyr-based/zephyr/arch/arm/core/aarch32/cortex_m/reset.S:69 Thread 1 (Thread 57005): #0 z_arm_reset () at /home/ted/projects/zephyr-based/zephyr/arch/arm/core/aarch32/cortex_m/reset.S:69
This listing of backtraces however is short lived. In a given gdb session, the second and later times I invoke this command the report gives only Thread 2 has extent and having a backtrace to report.
Question (1) Is there a sequence of debugging commands I must issue, to put firmware into a state where the debugger can correctly report Zephyr and app threads?
Question (2) should Segger's Zephyr RTOS plugin shared object file support gdb to list the same threads which Zephyr itself reports?
- Ted
