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?
Compile time of what? All these things should be known by the time the linker has pulled it all together.
The DSP code compilation is a separate operation, right? Then you're trying to integrate that object code into some other Cortex-M3 app that payloads it to it's final destination on the DSP.
Then perhaps your "DSP object to 'C' structure at" translation program needs to do a better job at building tables that tie all this together so processing can be achieved at run-time, or that it acts more like a loader.
for reference:
cortex.elf depends on dsp.o depends on dsp.c depends on dsp.elf depends on a bunch of other files that are irrelevant.
DSP.C places all the right values at all the right locations in memory via C arrays located using __attribute((at()) (the DSP memory is linearly mapped into cortex memory on the peripheral bus). There is an array for every dsp.elf section with initialized data for every value(either zeros or data)for every word in dsp memory that is referenced by DSP.ELF.
When the debugger loads the contents of the module DSP.O into memory at load time (should get all .data sections), and __scatterload is performed (should get all .bss/zeroinit sections) then the DSP should be completely populated without any other magic that needs to happen. No fixup, no copying, etc.
Well, or at least it should be this way. The zero init sections aren't ending up in the linker created list that __scatterload uses, and I can't figure a way to convince the linker to do such a thing.
It's not super huge, as our production bootloader zeros out the zero init sections because it references the cortex elf (which specifies them), and our debug flow can blanket zero out the DSP memory prior to enabling jtag.
But it is irritating and seems to be a bug in the keil linker.
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?