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
No need for two projects - one project with two targets can also manage.
The important thing is to not try to manage this with a single compilation/linking. It's enough that the Keil tools gets updated and that the CRTL gets some modifications - both the "fixed" and the non-fixed part will most probably make use of one or more CRTL functions. Or some helper code the compiler uses for long-long multiplication etc.
The problem with getting everything in a single build is that it can look good - until you already have 10k units out in the field, and finally realize that you can't build any updates that are compatible with the already shipped units.
With two separate builds, it doesn't matter if a compiler update will result in a change of the "fixed" part. Having separated everything into two builds, you can still continue to use the older fixed part together with a newly built variable part. It's enough that the "contract" you originally defined for interaction is still fulfilled.
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.