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 >> >
