Datasheet

You can see here that line 46 of crash_test.c caused the fault, which is where the divide by zero error occurs.

Option 2: Debugging Crash Dumps with objdump

If you have the .elf file but can't use GDB debugger you can see the code for the specified address from the command

line using the objdump tool that is part of GCC.

From the command-line (with GCC available as part of the system path) run the following command:

Note: You must specify a --stop-address that is higher than the --start-address with this command, but you can

increment the hex value by 1 byte to return only the line of code that caused the crash. You can play with the start

and stop addresses to provide some context to the error.

Debugging Repeatable Crashes

If you can repeat the crash scenario, you can find out the cause with the following sequence of events and two

terminal windows:

Run GDB with the following command:

(gdb) monitor go

(gdb) list *0x00009e54

0x9e54 is in crash_device (crash_test.c:46).

41 if (!strcmp(how, "div0")) {

43 val1 = 42;

44 val2 = 0;

46 val3 = val1 / val2;

47 console_printf("42/0 = %d\n", val3);

48 } else if (!strcmp(how, "jump0")) {

49 ((void (*)(void))0)();

50 } else if (!strcmp(how, "ref0")) {

$ arm-none-eabi-objdump -S --start-address=0x00009e54 --stop-address=0x00009e55 bin/targets/throughput/app/apps/throughput/throughput.elf

bin/targets/throughput/app/apps/throughput/throughput.elf: file format elf32-littlearm

Disassembly of section .text:

00009e54 <crash_device+0x1c>:

if (!strcmp(how, "div0")) {

val1 = 42;

val2 = 0;

val3 = val1 / val2;

9e54: fb93 f3f2 sdiv r3, r3, r2

$ newt run <target-name> 0