adamgreen/crashcatcher

Catch Hard Faults on Cortex-M devices and save out a crash dump to be used by CrashDebug.

crashcatcher's Issues

Armv8-M

Now the M33s are more and more common. Any plans for Armv8-M?
We will try with the Armv7-M config, but would you have some advice that might be useful? I hope that if we won't use the secure modes, it could be the same.

Support for lpc 1833

I am using LPC 1833.
Is your CrashCatcher code is work with LPC 1833(ARM Cortex M3)?
because after use of your code my finding are:
"vmrs r1, fpscr \n"
"vstmia.32 r0!, {s0 - s31} \n"
these above instructions are not supported and give error like(selected processor does not support Thumb mode `vmrs r1,fpscr'). these instruction are useful for HexDump Routines.
so, how to use HexDump Routines?

Dump without crash?

Thank you for this library. Very useful. I was able to get it working on an LPC4370. But is there any way to produce a dump without inducing a fault? Sometimes I'd like to just get a stack trace and let the program continue running. I tried calling HardFault_Handler() directly and returning CRASH_CATCHER_EXIT from CrashCatcher_DumpEnd but this seems to just freeze.

Failed to build CppUTest in CrashCatcher

Failed to build CppUTest in CrashCatcher
commands : make clean all

...
Compiling FloatMocks/tests/AllTests.cpp
Compiling FloatMocks/tests/FloatMocksTests.cpp
FloatMocks/tests/FloatMocksTests.cpp: In member function ‘virtual void TEST_FloatMocks_SetAllFloatingPointRegisters_ValidateCopyUsesThoseValues_Test::testBody()’:
FloatMocks/tests/FloatMocksTests.cpp:50:43: error: ‘memset’ was not declared in this scope
     memset(floatRegs, 0, sizeof(floatRegs));
                                           ^
In file included from CppUTest/include/CppUTest/TestHarness.h:72:0,
                 from FloatMocks/tests/FloatMocksTests.cpp:24:
FloatMocks/tests/FloatMocksTests.cpp:52:75: error: ‘memcmp’ was not declared in this scope
     CHECK_TRUE(0 == memcmp(testFloatRegs, floatRegs, sizeof(testFloatRegs)));
                                                                           ^
CppUTest/include/CppUTest/UtestMacros.h:93:43: note: in definition of macro ‘CHECK_LOCATION_TRUE’
   { UtestShell::getCurrent()->assertTrue((condition) != 0, checkString, conditionString, file, line); }
                                           ^
FloatMocks/tests/FloatMocksTests.cpp:52:5: note: in expansion of macro ‘CHECK_TRUE’
     CHECK_TRUE(0 == memcmp(testFloatRegs, floatRegs, sizeof(testFloatRegs)));
     ^
FloatMocks/tests/FloatMocksTests.cpp: In member function ‘virtual void TEST_FloatMocks_SetUpperFloatingPointRegisters_ValidateCopyUsesThoseValues_Test::testBody()’:
FloatMocks/tests/FloatMocksTests.cpp:63:43: error: ‘memset’ was not declared in this scope
     memset(floatRegs, 0, sizeof(floatRegs));
                                           ^
In file included from CppUTest/include/CppUTest/TestHarness.h:72:0,
                 from FloatMocks/tests/FloatMocksTests.cpp:24:
FloatMocks/tests/FloatMocksTests.cpp:65:75: error: ‘memcmp’ was not declared in this scope
     CHECK_TRUE(0 == memcmp(testFloatRegs, floatRegs, sizeof(testFloatRegs)));
                                                                           ^
CppUTest/include/CppUTest/UtestMacros.h:93:43: note: in definition of macro ‘CHECK_LOCATION_TRUE’
   { UtestShell::getCurrent()->assertTrue((condition) != 0, checkString, conditionString, file, line); }
                                           ^
FloatMocks/tests/FloatMocksTests.cpp:65:5: note: in expansion of macro ‘CHECK_TRUE’
     CHECK_TRUE(0 == memcmp(testFloatRegs, floatRegs, sizeof(testFloatRegs)));
     ^
makefile:336: recipe for target 'obj/host/FloatMocks/tests/FloatMocksTests.o' failed
make: *** [obj/host/FloatMocks/tests/FloatMocksTests.o] Error 1

Backtrace stopped: previous frame identical to this frame (corrupt stack?)

I have ported the CrashCatcher, and I made some test,
after the fault, the CrashCather will dump the carsh log,
then I put this command:

 arm-none-eabi-gdb mytest.elf -ex "set target-charset ASCII" -ex "target remote | ./CrashDebug --elf mytest.elf --dump crash.txt"

The gdb start correctly and find the right crash postion, but
when I input "bt", it shows

Backtrace stopped: previous frame identical to this frame (corrupt stack?)

following is the log:

(gdb) bt
#0  app_event_callback (chan=0x2000f048 <channel_pool>, 
    ctx=0x20014300 <os_thread_def_stack_MyTestThread+4420>)
    at ../../services/mytest.cpp:1567
#1  0x0c0393e8 in test_callback (Chan=0x20012e70 <app_device>, 
    Info=0x20014300 <os_thread_def_stack_MyTestThread+4420>)
    at ../../services/test_api.cpp:831
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Is there any reason for the corrupt stack. but I think the stack is right,maybe
unwind is not correct. Because I only add the following test code:

    char *a = NULL;
    *a = 125;
    TRACE("a %d", *a);

which will cause a NULL pointer dereference error.

RAM memory region load fail with elf

When running CrashDebug passing an elf file an exception is thrown when loading dump data to .dma section.
Passing the corresponding bin file works fine.

Command:
arm-none-eabi-gdb filename.elf -ex "set target-charset ASCII" -ex "target remote | CrashDebug --elf filename.elf --dump crash_dump.log"
Error:
ERROR: The dump file failed to load RAM memory region at 0x20078000 - 0x20080000
[...]
Encountered unexpected error: 19

elf file objdump excerpt :

CSNX.elf:     file format elf32-little
CSNX.elf
architecture: UNKNOWN!, flags 0x00000112:
EXEC_P, HAS_SYMS, D_PAGED
start address 0x080b7295

Program Header:
    LOAD off    0x000000c0 vaddr 0x08040000 paddr 0x08040000 align 2**6
         filesz 0x000c86b0 memsz 0x000c86b0 flags rwx
    LOAD off    0x000c8770 vaddr 0x20000000 paddr 0x081086b0 align 2**3
         filesz 0x0000be18 memsz 0x0000be18 flags rw-
    LOAD off    0x000d4588 vaddr 0x2000be18 paddr 0x2000be18 align 2**3
         filesz 0x00000000 memsz 0x0004d898 flags rw-
    LOAD off    0x000d4588 vaddr 0x20078000 paddr 0x20078000 align 2**2
         filesz 0x000040a0 memsz 0x000040a0 flags rw-

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .isr_vector   000001f8  08040000  08040000  000000c0  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  1 .build_info   00000088  080401f8  080401f8  000002b8  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  2 .text         000afc58  08040280  08040280  00000340  2**6
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  3 .rodata       00018400  080efed8  080efed8  000aff98  2**3
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  4 .ARM.extab    00000148  081082d8  081082d8  000c8398  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  5 .ARM          00000250  08108420  08108420  000c84e0  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  6 .preinit_array 00000000  08108670  08108670  000d8628  2**0
                  CONTENTS, ALLOC, LOAD, DATA
  7 .init_array   00000038  08108670  08108670  000c8730  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  8 .fini_array   00000008  081086a8  081086a8  000c8768  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  9 .data         0000be18  20000000  081086b0  000c8770  2**3
                  CONTENTS, ALLOC, LOAD, DATA
 10 .dma          000040a0  20078000  20078000  000d4588  2**2
                  CONTENTS, ALLOC, LOAD, DATA
 11 .bss          00049094  2000be18  2000be18  000d4588  2**3
                  ALLOC
 12 ._user_heap_stack 00004804  20054eac  20054eac  000d4588  2**0
                  ALLOC
 13 .ARM.attributes 0000002e  00000000  00000000  000d8628  2**0
                  CONTENTS, READONLY
 14 .debug_frame  000b77fc  00000000  00000000  000d8658  2**2
                  CONTENTS, READONLY, DEBUGGING, OCTETS
 15 .debug_info   0097020e  00000000  00000000  0018fe54  2**0
                  CONTENTS, READONLY, DEBUGGING, OCTETS
 16 .debug_abbrev 00066390  00000000  00000000  00b00062  2**0
                  CONTENTS, READONLY, DEBUGGING, OCTETS
 17 .debug_aranges 000264d0  00000000  00000000  00b663f8  2**3
                  CONTENTS, READONLY, DEBUGGING, OCTETS
 18 .debug_ranges 00025f10  00000000  00000000  00b8c8c8  2**3
                  CONTENTS, READONLY, DEBUGGING, OCTETS
 19 .debug_line   00107715  00000000  00000000  00bb27d8  2**0
                  CONTENTS, READONLY, DEBUGGING, OCTETS
 20 .debug_str    0070bf94  00000000  00000000  00cb9eed  2**0
                  CONTENTS, READONLY, DEBUGGING, OCTETS
 21 .comment      00000079  00000000  00000000  013c5e81  2**0
                  CONTENTS, READONLY
SYMBOL TABLE:
08040000 l    d  .isr_vector    00000000 .isr_vector
080401f8 l    d  .build_info    00000000 .build_info
08040280 l    d  .text  00000000 .text
080efed8 l    d  .rodata        00000000 .rodata
081082d8 l    d  .ARM.extab     00000000 .ARM.extab
08108420 l    d  .ARM   00000000 .ARM
08108670 l    d  .preinit_array 00000000 .preinit_array
08108670 l    d  .init_array    00000000 .init_array
[...]

crash_dump.log

The dump file failed to load RAM memory region with elf

--confidential--

No CrashDump when using gcc flag "-Og"

No CrashDump is created when using compiler flag (arm-non-eabi-gcc) "-Og", which is a good flag for debugging. Using other flags like "-O2" or even "-O -g" causes no problems and the dump can be used with CrashDebug.

Do you have any ideas, @adamgreen? Already much thanks for your work and your great tool!

Program/IDE to view post-mortem crash

I was curious what program you use or would recommend using to view the crash? Something like GDB or qemu?

Corrupt Backtrace

Hi,

I'm trying to integrate your great library into my project. Unfortunately I encounter some problems. My example application looks like this:

void func_3(void)
{
    volatile int i = 0;
    __builtin_trap();
}

void func_2(void)
{
    func_3();
}

void func_1(void)
{
    func_2();
}

int main(int argc, char const *argv[])
{
    func_1();
    return 0;
}

The Crash dump:

63430300
01000000
00000000000000008802002000000000
000000000000000000000000D0FF0320
00000000000000000000032000000000
00000000
D0FF0320
3D0700003207000000000061
B0FF03200000000003000060
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000
28ED00E03CED00E0
00000100000000400000000034ED00E0
38ED00E0

and the gdb output:

Reading symbols from ./_build/nrf52840_xxaa.out...
Remote debugging using | ./CrashDebug --elf ./_build/nrf52840_xxaa.out --dump crash.txt
0x00000732 in func_3 () at main.c:4
4           volatile int i = 0;
#0  0x00000732 in func_3 () at main.c:4
        i = <error reading variable i (Cannot access memory at address 0x2003ffd4)>
Backtrace stopped: Cannot access memory at address 0x2003ffdc
A debugging session is active.

Is there a way to understand the problem in more detail? Why is the stack not fully unwinded until main?

Compiler: Gcc 7.3
MCU: Nordic NRF52840
Compiled with "O0".