Hello,
I want to split my program, so that about half of my c modules are linked starting from 0 and the other half starting from 0x4000. I configured the L166 to "use linker control file" (project options -> L166 Misc) and defined withing the rec.lin file a new section "..., MYSPECIALCODE (0x4000-0x7FFF), ..."
But how do I tell the linker what c and h files should be within the MYSPECIALCODE section??
Hoping for help
Tobi
How would it work to seperate the two parts in two builds and reuniting them into one target??
I thought about compiling one part to a library file, the problem is the entry point of the software is in the fixed part, so I can only make the non-fixed part to a library file. But the non-fixed part references some of the fixed-part's variables (not vice-versa). Even if it would work to seperate the non-fixed part to a library file and including it into the project with the fixed part, I'm not sure if this would get any better results concerning the "stability" of the fixed part.
Updates of the Keil compiler / linker / or any part of the development chain can be be ruled out, that's not an issue.
I asked you three days ago: "I think you better explain more. WHY do you not want one part of the code to change?"
As long as you ignore that question, we have a hard time helping you. We can see your issues but can't know what alternatives to suggest if we don't know what problem you feel you need to solve. All you have said is that it isn't related to a boot loader.
Having a fixed part call functions in a non-fixed part can be done by the use of a jump table at a fixed - and known - location.
Having a non-fixed part call functions in a fixed part can be done since the fixed part would have known addresses for the functions. Or by using a jump table.
"How would it work to seperate the two parts in two builds and reuniting them into one target??"
Only by having the two parts separately built, can you be sure that the two parts could be individually linked without any hidden accesses to the other part (such as global variables used inside the CRTL, or helper functions etc).
It wouldn't. Which is why we advised you not to do it that way.
Forget about the "one target" idea. You will be flashing two independently built targets onto the same hardware, either by merging the hex filex before flashing, or by flashing both binaries in sequence.