In our ASIC, we have multiple cores: a cortex M series, plus a DSP. The separate DSP core is getting it's memory poplulated by it's output elf into several arrays that are located (using the __attribute__((at(x)) method) at the correct shared memory location as seen by the Cortex, and that C file is compiled into the cortex image.
We do this so that uVision can load the DSP's memory as well.
Unfortunately, it seems like the linker trickery used to make this happen doesn't put the sections that should be zero init in the list of things to be initialized by __scatterload_zeroinit (or i.__scatterload_zeroinit).
These .bss-ish sections do end up in the elf file (because our post processing tool that converts the cortex mcu AXF to a flash image knows what to do), but when loading from the debugger all these specifically placed .bss sections (initialized arrays of all zeros) don't end up being initialized by __scatterload during startup.
Any help with this? Is this a keil tool bug? Am I doing it wrong?
For your "attribute((at(x)) .bss sections" to stand any chance of being scatter loaded, they are going to need to get into you LR_IRAM1 load region so they get described and tabled for processing. They have to be described in some load region, because the scatter loader is designed to move things, typically unpacking from a rom image into uninitialize ram regions. I'm not sure what you're describing is a bug in the linker, but if it were you'd need to create a worked example and provide that to the support group.
What's to stop you skipping the whole DSP.ELF -> DSP.C step, and instead merge the .HEX or .ELF for the DSP blobs with the Cortex .HEX or .ELF as a post link step?