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
I believe the answer is here:
http://www.keil.com/support/docs/2215.htm
By the way, why would you want to do this? If you are designing a bootloader, that's the wrong way to do it.
thank you very much, thats what I needed.
(no it's not for a boot loader, just to ensure one part of the code doesn't change)
just to ensure one part of the code doesn't change
What if the code that's not supposed to change references variables and functions from the code that IS supposed to change? Surely the addresses of those variables and functions will change?
I think you better explain more. WHY do you not want one part of the code to change? That very much sounds like you plan to remote-update the other part of the code. Which would imply a boot loader, even if you maybe don't decide to call it a boot loader.
Never, ever, try a situation where you modify and recompile your code, and you expect some part of the program to not change. The compiler is not designed to give such promises. You always have to assume that things can change.
Then it's a good thing we asked for your ultimate goal: that's not going to get you closer to it.
People try this for boot loaders to achieve the same goal: keep the boot loader part from changing as the application changes. And they fail for the same reason your code would: splitting up code into two separate regions does not at all ensure that one of them stays the same.
Experience shows that the only reliable way of avoiding changes to the fixed region (boot loader / kernel / function library, or whatever you name it) regardless of what happens in the variable part ("application"), is for the the application to remain strictly outside the picture while you build the fixed part. Yes, that means you will need (at least) two separate projects for fixed and variable part.
And you may have to figure out a way to tell the variable part build about some points of reference in the fixed image (addresses of entry points, description tables, that kind of stuff). Some tools allow to include (just the symbol information of) a pre-linked binary into the build for that purpose, for others you may have to do this the hard way, by fixing these addresses prior to building the fixed part, and making those same fixed addresses known to the application, too. The latter technique will definitely be needed for all things in the application that need to be known to the fixed part (entry point, mainly).
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.