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
