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 >
