|
| 1 | +# Troubleshooting |
| 2 | +General overview of tools used to troubleshoot the template and/or modem/network behavior. |
| 3 | +It's recommended to complete the Nordic Developer Academy lesson: [Debugging and troubleshooting](https://academy.nordicsemi.com/courses/nrf-connect-sdk-intermediate/lessons/lesson-2-debugging/) for tips in general how to debug applications based on [nRF Connect SDK](https://github.com/nrfconnect/sdk-nrf). |
| 4 | + |
| 5 | +# Shell |
| 6 | +To control and get information about certain aspects of the template, shell can be used. |
| 7 | +To use shell, connect to the devices UART interface either via your own terminal or the [nRF Connect for Desktop](https://www.nordicsemi.com/Products/Development-tools/nRF-Connect-for-Desktop) Serial terminal application. |
| 8 | +Here is an example of how shell can be used to send a message to [nRF Cloud](https://nrfcloud.com): |
| 9 | + |
| 10 | +``` |
| 11 | +uart:~$ att_cloud_publish TEMP "24" |
| 12 | +Sending on payload channel: {"messageType":"DATA","appId":"TEMP","data":"24","ts":1744359144653} (68 bytes) |
| 13 | +``` |
| 14 | + |
| 15 | +The following command "help" lists all the available commands in the template: |
| 16 | + |
| 17 | +``` |
| 18 | +uart:~$ help |
| 19 | +Available commands: |
| 20 | + at : Execute an AT command |
| 21 | + att_button_press : Asset Tracker Template Button CMDs |
| 22 | + att_cloud_publish : Asset Tracker Template Cloud CMDs |
| 23 | + att_network : Asset Tracker Template Network CMDs |
| 24 | + mflt_nrf : Memfault nRF Connect SDK Test Commands |
| 25 | + ... |
| 26 | +``` |
| 27 | + |
| 28 | +The commands prefixed *att* are commands that are specific to the template. |
| 29 | +These shell commands are implemented in shell modules corresponding to the aspect of the template they control. |
| 30 | +For example, the network module implements the file `network_shell.c` and is located in the module folder. |
| 31 | + |
| 32 | +# Low Power Profiling |
| 33 | +The Power consumption of the device can be profiled using PPK. |
| 34 | + |
| 35 | +# Debugging using West (GDB) |
| 36 | +The template can be easily debugged using GDB via the west commands `west attach`. |
| 37 | +The following example shows how GDB can be used to set a breakpoint and print a backtrace once the breakpoint is hit: |
| 38 | + |
| 39 | +``` |
| 40 | +Insert terminal session showing how its used here. |
| 41 | +``` |
| 42 | + |
| 43 | +Fore more information about debugging with west, see [West debugging](https://docs.zephyrproject.org/latest/develop/west/build-flash-debug.html#debugging-west-debug-west-debugserver) |
| 44 | + |
| 45 | +# Debugging using SEGGER SystemView |
| 46 | +[Segger SystemView](https://www.segger.com/products/development-tools/systemview/) is a real-time analysis tool that can be used to analyse thread execution and scheduling in the device. |
| 47 | +To build the template with RTT tracing to Segger SystemView set the following options in your build configuration: |
| 48 | + |
| 49 | +``` |
| 50 | +CONFIG_TRACING=y |
| 51 | +CONFIG_USE_SEGGER_RTT=y |
| 52 | +CONFIG_SEGGER_SYSTEMVIEW=y |
| 53 | +CONFIG_SEGGER_SYSTEMVIEW_BOOT_ENABLE=n |
| 54 | +CONFIG_SEGGER_SYSVIEW_POST_MORTEM_MODE=n |
| 55 | +
|
| 56 | +``` |
| 57 | + |
| 58 | +Or build with the predefined RTT trace snippet: |
| 59 | + |
| 60 | +``` |
| 61 | +west build -p -b <board> -S rtt-tracing |
| 62 | +``` |
| 63 | + |
| 64 | +Note that this snippet disables debug optimizations and that it may not be enough space in your application to use it as disabling optimizations increases the overall memory use of the application. |
| 65 | + |
| 66 | +# Thread Analyser |
| 67 | +The Trace analyzer subsystem is useful when optimizing the applications stack sizes. |
| 68 | +Add the following options to your build configurations to get stack information printed every 30 seconds: |
| 69 | + |
| 70 | +``` |
| 71 | +CONFIG_THREAD_ANALYZER=y |
| 72 | +CONFIG_THREAD_ANALYZER_USE_LOG=y |
| 73 | +CONFIG_THREAD_ANALYZER_AUTO=y |
| 74 | +CONFIG_THREAD_ANALYZER_AUTO_INTERVAL=30 |
| 75 | +CONFIG_THREAD_ANALYZER_AUTO_STACK_SIZE=1024 |
| 76 | +CONFIG_THREAD_NAME=y |
| 77 | +``` |
| 78 | + |
| 79 | +# TF-M logging |
| 80 | +To get logs from the secure image TF-M of the application forwarded to UART0 (application UART output) you can build with the following snippet: |
| 81 | + |
| 82 | +``` |
| 83 | +west build -p -b <board> -S tfm-enable-share-uart |
| 84 | +``` |
| 85 | + |
| 86 | +In case of secure faults, the fault frame information will be printed with accompanied information of the violating non-secure SP and LR registers. |
| 87 | + |
| 88 | +# Debugging using Memfault (Remote debugging) |
| 89 | +The template implements overlays to enable remote debugging to [Memfault](https://memfault.com/). |
| 90 | +To get familiar with Memfault and how to do remote debugging, its recommended to go through the Nordic Developer Academy excersise: [Remote Debugging with Memfault](https://academy.nordicsemi.com/courses/nrf-connect-sdk-intermediate/lessons/lesson-2-debugging/topic/exercise-4-remote-debugging-with-memfault/) |
| 91 | + |
| 92 | +Refer to the [Getting Started](getting_started.md) section to see how the template can be built with overlays enabling Memfault functionality. |
| 93 | +If you want to test/simulate faults on the device to test Memfault, the template implements Memfault shell commands that can be used to trigger typical faults. |
| 94 | +Here is an example of triggering a usagefault: |
| 95 | + |
| 96 | +``` |
| 97 | +insert example here |
| 98 | +``` |
| 99 | + |
| 100 | +Fore more information on NCSs Memfault implementation, refer to the Memfault NCS sample documentation, integration as well as the templates CI Memfault on-target tests: |
| 101 | + |
| 102 | +* [Memfault sample](https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/samples/debug/memfault/README.html) |
| 103 | +* [Memfault integration](https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/libraries/debug/memfault_ncs.html) |
| 104 | +* [CI tests](Asset-Tracker-Template/tests/on_target/tests/test_functional/test_memfault.py) |
| 105 | + |
| 106 | +To use Memfault, you will need to register and setup a project. |
| 107 | +This can be done via the following link, [Memfault registration page](https://app.memfault.com/register-nordic) |
| 108 | + |
| 109 | +# Debugging using Modem traces |
| 110 | +Modem traces can be captured over UART to debug LTE, IP, and modem issues. |
| 111 | +This can be done by including a snippet in the build command specifying which medium you want to trace to. |
| 112 | +This build command enables modem tracing over UART1: |
| 113 | + |
| 114 | +``` |
| 115 | +west build -p -b <board> -S nrf91-modem-trace-uart |
| 116 | +``` |
| 117 | + |
| 118 | +This build commands enables modem tracing over RTT: |
| 119 | + |
| 120 | +``` |
| 121 | +west build -p -b <board> -S nrf91-modem-trace-uart |
| 122 | +``` |
| 123 | + |
| 124 | +To capture modem traces over UART on a host computer either [nRF Connect for Desktop](https://www.nordicsemi.com/Products/Development-tools/) Cellular Monitor application can be used nRFUtil CLI: |
| 125 | + |
| 126 | +``` |
| 127 | +nrfutil trace lte --input-serialport /dev/ttyACM1 --output-pcapng trace |
| 128 | +``` |
| 129 | + |
| 130 | +for RTT traces you can use the RTT logger to capture the modem traces and later convert them to PCAP using nRF Util or the Cellular Monitor: |
| 131 | + |
| 132 | +``` |
| 133 | +JLinkRTTLogger -Device NRF9160_XXAA -If SWD -RTTChannel 1 modem_trace.bin |
| 134 | +``` |
| 135 | + |
| 136 | +If you also want to route logging via RTT you can capture both modem traces and application logs at the same time using debuggers RTT multichannel functionality. |
| 137 | +To do so you build the application with the RTT modem trace snippet and add the following options to the project configurations: |
| 138 | + |
| 139 | +``` |
| 140 | +CONFIG_USE_SEGGER_RTT=y |
| 141 | +CONFIG_LOG_BACKEND_RTT=y |
| 142 | +CONFIG_SHELL_BACKEND_RTT=y |
| 143 | +CONFIG_SHELL_BACKEND_RTT_BUFFER=1 |
| 144 | +``` |
| 145 | + |
| 146 | +This will split RTT tracing and logging into two channels, the you can call two separate commands to trace on both channels: |
| 147 | + |
| 148 | +Terminal 1: |
| 149 | + |
| 150 | +``` |
| 151 | +JLinkRTTLogger -Device NRF9160_XXAA -If SWD -RTTChannel 1 modem_trace.bin |
| 152 | +``` |
| 153 | + |
| 154 | +Terminal 2: |
| 155 | + |
| 156 | +``` |
| 157 | +JLinkRTTLogger -Device NRF9160_XXAA -If SWD -Speed 50000 -RTTChannel 0 terminal.txt |
| 158 | +``` |
| 159 | + |
| 160 | +Just remember that the modem trace is captured in a binary format that needs to be converted by either nRF Util or the Cellular Monitor application. |
| 161 | +To convert a binary modem trace using nRF Util you can use the following command: |
| 162 | + |
| 163 | +``` |
| 164 | +nrfutil trace lte --input-file modemtraces.bin --output-wireshark |
| 165 | +``` |
| 166 | + |
| 167 | +Its recommended to go through the [Nordic Developer Academy Debugging with a Modem Trace excersise](https://academy.nordicsemi.com/courses/cellular-iot-fundamentals/lessons/lesson-7-cellular-fundamentals/) to familiarize yourself with modem tracing on the nRF91 Series. |
| 168 | + |
| 169 | +# Common issues |
| 170 | + |
| 171 | +## Not getting connected to network |
| 172 | +- problem (description, UART/trace output) - |
| 173 | +- suggested tooling/debuggin to find the source of the issue - (modem trace / memfault) |
| 174 | +- Suggested fixes - |
| 175 | +- Link to similar devzone cases - |
| 176 | + |
| 177 | +## Cloud connection timeout |
| 178 | +- problem (description, UART/trace output) - |
| 179 | +- suggested tooling/debuggin to find the source of the issue - (modem trace / memfault) |
| 180 | +- Suggested fixes - |
| 181 | +- Link to similar devzone cases - |
0 commit comments