Hi all, package for coredumps is now checked into develop branch for core and newt. This is for offline analysis of things that went wrong.
To use this, you must include the sys/coredump package in your app’s pkg.yml file. Now, if you get an unhandled exception, or your app asserts, we try to collect a coredump. This at the moment goes to flash, on the 2nd image slot. If there already is a corefile there, it will not be overwritten. If there is an image there, it will be overwritten. To get the coredump out of the target, use newtmgr. 'newtmgr -c <conn> image corelist’ shows if core is present. ‘newtmgr -c <conn> image coredownload <file>’ loads the coredump, converts it into ELF format, and places it in <file>. ‘newtmgr -c <target> image coreerase’ removes this coredump from the target. After you have this corefile you can inspect it along with the elf file which generated it. Now, the version of gdb we use does not have support for corefiles, so you’ll need to build a new one. Here’s what I did for this: On Mac: tar xvzf gdb-7.8.1.tar.gz cd gdb-7.8.1 ./configure --target=arm-elf-linux --without-lzma --without-guile --without-libunwind-ia64 --with-zlib make gdb/gdb -v And with Linux (I’m running Ubuntu 14.04): sudo apt-get install zlibc zlib1g zlib1g-dev libexpat-dev libncurses5-dev liblzma-dev tar xvzf gdb-7.8.1.tar.gz cd gdb-7.8.1 ./configure --target=arm-elf-linux --with-lzma --with-expat --without-libunwind-ia64 --with-zlib --without-babeltrace make gdb/gdb -v And this is what it should look like: [marko@IsMyLaptop:~/src/incubator-mynewt-blinky]$ newtmgr -c olimex image corelist Corefile present [marko@IsMyLaptop:~/src/incubator-mynewt-blinky]$ newtmgr -c olimex image coredownload ~/core Coredump download completed Corefile created for bfae72e4d51761bf987329e40a44d9cca6926741a88684725c25f94095c00c7d [marko@IsMyLaptop:~/src/incubator-mynewt-blinky]$ arm-elf-linux-gdb bin/slinky_zero/apps/slinky/slinky.elf ~/core GNU gdb (GDB) 7.8.1 Copyright (C) 2014 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "--host=x86_64-apple-darwin14.5.0 --target=arm-elf-linux". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from bin/slinky_zero/apps/slinky/slinky.elf...done. [New process 1] #0 0x0000c234 in coredump (argc=<optimized out>, argv=<optimized out>) at main.c:258 258 *(int *)0x7fffff0 = 0; (gdb) list 253 if (argc < 2) { 254 console_printf("Need more args: hf | assert | reset\n"); 255 return 0; 256 } 257 if (!strcmp(argv[1], "hf")) { 258 *(int *)0x7fffff0 = 0; 259 } else if (!strcmp(argv[1], "assert")) { 260 assert(0); 261 } else if (!strcmp(argv[1], "reset")) { 262 system_reset(); (gdb) bt #0 0x0000c234 in coredump (argc=<optimized out>, argv=<optimized out>) at main.c:258 #1 0x000153f0 in shell_cmd (argc=2, argv=0x200011b4 <argv>, cmd=0x20005500 "core") at shell.c:169 #2 shell_process_command (line=<optimized out>, len=len@entry=7) at shell.c:199 #3 0x0001556e in shell_read_console () at shell.c:445 #4 shell_task_func (arg=<optimized out>) at shell.c:481 #5 0x00000000 in ?? () Backtrace stopped: previous frame identical to this frame (corrupt stack?) (gdb) info reg r0 0x0 0 r1 0x1a848 108616 r2 0x0 0 r3 0x7fffff0 134217712 r4 0x20005505 536892677 r5 0x200000d0 536871120 r6 0x20005500 536892672 r7 0x20001240 536875584 r8 0xc 12 r9 0x1c 28 r10 0xc 12 r11 0x13 19 r12 0x2a 42 sp 0x20002478 0x20002478 <shell_stack+1400> lr 0xc22d 49709 pc 0xc234 0xc234 <coredump+32> cpsr 0x61000000 1627389952 (gdb) The coredump contains the hash of the image which generated it. So you can eyeball that one against the image you built and make sure that you have elf file which matches your core. Let me know if you give this a go, M > On May 17, 2016, at 1:45 PM, marko kiiskila <[email protected]> wrote: > > It would be quite a bit of work for a very specialized feature :) > Modifying BSP’s array of memory regions should be easy > enough to do in the cases where peripheral memory is > wanted, IMHO. > >> On May 17, 2016, at 1:31 PM, will sanfilippo <[email protected]> wrote: >> >> Sounds good. I see if you have an array at the bsp you could just add the >> peripherals to that array…I was thinking more along the lines of an API that >> would allow an application developer to pick and choose peripherals but that >> might be a bit much... >> >> Will >> >> >>> On May 17, 2016, at 12:21 PM, marko kiiskila <[email protected]> wrote: >>> >>> Hi Will, >>> >>> I was going to collect all the SRAM to start with. Once >>> all is working, and the size of the core becomes an >>> issue, then start cutting down. >>> >>> There’s nothing stopping you from collecting peripheral >>> register state, as long as the registers are memory mapped. >>> Just need to tell coredump collector somehow that this >>> is the region you want collected. >>> >>>> On May 17, 2016, at 9:46 AM, will sanfilippo <[email protected]> wrote: >>>> >>>> When you say “dump all the RAM” are you referring to the entire RAM >>>> available on the chip or just the portions that are used? And by used I >>>> also mean including the heap that was used, exception stacks, .bss, .data, >>>> etc. >>>> >>>> I am sure you have thought of this, but maybe the 3rd rev would allow for >>>> developers to dump peripherals as well? >>>> >>>> >>>>> On May 16, 2016, at 2:51 PM, marko kiiskila <[email protected]> wrote: >>>>> >>>>> Hi, >>>>> >>>>> I’ve started implementing support for core dump generation. >>>>> Core would be generated on assert() and on unhandled >>>>> exceptions. >>>>> This would be placed somewhere on flash, and then you >>>>> can download it from target and use it together with the >>>>> built binary to look at system state at the time of the fault. >>>>> >>>>> For the initial implementation, I was going to dump all the >>>>> RAM present in the system, and just assume that there >>>>> would be enough flash space to keep it. >>>>> The info about memory ranges could come from BSP(?) in >>>>> form of an array. >>>>> I assume BSP would be the right owner for this data. Unless >>>>> there are countering opinions? >>>>> >>>>> The 2nd rev of coredumping would then allow user to have >>>>> an option for smaller dump. This would not contain all >>>>> RAM, but rather a subset. I was thinking of only including the >>>>> stack of the currently running task in it. Of course, this would be >>>>> for later. >>>>> — >>>>> M >>>> >>> >> >
