Datasheet

Field Debugging Tips

Debugging devices deployed remotely is always a challenge but this documentation gives some basic techniques to

help debug issues remotely.

Debugging Crash Dumps

If a task crashes (enter the fault_handler etc.) it will normally generate a simple dump of the system registers, which

can be useful to find the cause of the problem if you have the matching .elf file locally.

This example uses the crash_test library from apache-mynewt-core to simulate various crash events locally via

the crash command from shell:

In the example above we see the output of a divide by zero crash.

The important register value is pc . Make a note of this address since your will use it in one of the debugging methods

described below:

Option 1: Debugging Crash Dumps with GDB

If you have access to the matching app revision, build the target and deploy it to the device under test:

To start GDB via the following command:

This will start up the GDB server and connect to the device under test.

See GDB Debugging (https://adafru.it/Erw) for details on using GDB.

Run the following commands from the GDB shell:

crash div0

6976:Unhandled interrupt (3), exception sp 0x2000a960

6976: r0:0x00000000 r1:0x000242bd r2:0x00000000 r3:0x0000002a

6976: r4:0x00000000 r5:0x2000c002 r6:0x2000bffc r7:0x00025e34

6976: r8:0x0000d04d r9:0x0000000c r10:0x20009068 r11:0x55555556

6976:r12:0x00000000 lr:0x00009e45 pc:0x00009e54 psr:0x61000000

6976:ICSR:0x00419803 HFSR:0x40000000 CFSR:0x02000000

6976:BFAR:0xe000ed38 MMFAR:0xe000ed34

$ newt build throughput

$ newt create-image throughput 0.1.0

$ newt load throughput

$ newt debug throughput

Please note that you will require a Segger J-Link to run the 'newt debug' command!

