I have a Cortex-M3 based system (Silicon Labs EFM32GG MCU, with 1MB FLASH, 128k RAM) that runs a bootloader and application. The only contract between the two is that we know to build applications for offset 0x1000, since that's where the bootloader jumps to launch the application.
I now want to define a .noinit section for my application. If it faults, in the HFH I grab a register dump and copy it to a variable defined in the .noinit section, set a magic number in that same section, and then call NVIC_SystemReset(). This is as lean a HFH as I can think of, it doesn't try to access any peripherals.
Once re-booted, the application checks the magic number (and zeros it) and can 'phone home' the fault dump (I am in the ocean, and have only Iridium sat comms, there is no user console to harvest the fault dump).
In the application's .ld script, I have to ensure that the placement of the .noinit section does not overlap with ANY portion of ram that the bootloader might use (write to!). It's no use having a noinit section that the application's reset_handler won't touch, it must also be NOT touched by the bootloader!
Currently, I am defining the .noinit section AFTER my application's .heap, using the likely-true assumption that
APPLICATION(.data+.bss+.heap) > BOOTLOADER(.data+.bss+.heap)
since the application's ram requirements should be a lot larger than those of the bootloader.
I get the feeling this a 'hack'. Anyone have any better strategies? Am I overlooking anything? I'd like to maintain the minimal shared knowledge between bootloader + app that I have now (as of now, applications have NO idea about bootloader's RAM usage).
This may be of some help.