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