We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
I habe built a project with µVision2 and generated a library (LIB file). I have imported this LIB into another µVision2 project. However, the link order of the imported modules within the LIB is now changed compared to the original order of the modules. This is a problem since I have to keep not only the module order, but also the init_segment should be kept invariant. How can be kept the order of the included input module from the LIB? (I have used LIB51 LIBRARY MANAGER V4.24)
I have already located the imported segments from LIB to absolute addresses. After building the new project the new code will be automaticaly checked (binary compare) if the lower part of the new code is the same with the imported one. And this fails. The difference is always at the init segment: its size it's OK, but the content is different (mixed). I assume that it is because the LIB modules are somehow reordered in comparison to the original project and therefore the initialisation order of the imported modules will be also changed. Is there any way to fix this? Of course, I could import only the OBJ files instead, but the number of modules is high. And then it is more efficient to handle them in one single LIB.
If you've manually assigned addresses to the code segments, then the linker isn't going to reorder them.
By "init segment", do you mean ?C_INITSEG? This segment stores the values for initialized static variables. This segment will change for different programs depending on what variables you initialize statically (that is, with values in {} when you declare them). See the file INIT.A51. If you want this segment not to change, then all the rest of your code has to declare exactly the same initialized variables.
(For some applications, C_INITSEG is a waste of space. If the program has to be able to re-initialize itself short of a complete reboot, then you'll need additional code to set values anyway. The "free" initialization at declaration time is then redundant; INIT.A51 can be omitted entirely, and const code tables or immediate values used to store the init values. If, on the other hand, you have a lot of variables that really can be initialized only once, then INITSEG gathers all that information in one place and initializes everything at once, which can be more efficient that init code spread out in every module.)
Yes, I meant C_INITSEG. As I told, in the original project as well as in the new project the modules are alocated absolutely. Thus, other code segments are not changing, but this one. Static variable initialisation take place only in the original project, not in the new one. So I expect no change in C_INITSEG. Therefore I'm confused, why this segment will change by importing the LIB. What in my both project is missing is the INIT.A51 module. May be this the reason why in the new project the initialisation order for different imported modules will change?
ya init_seg
how do you do that?
I don't do anything... C51 and L51 do this somehow.
ok, r u sure?
ok,
I'm quite sure, I don't do any special handling, I have no INIT.A51 files but the static variables are correctly initialised (I have checked with the debugger). I'm using C51 V7.08.
When the linker order is important that most likely because you want to expand your project at a later point in time.
You should take a look to: http://www.keil.com/appnotes/docs/apnt_180.asp
This might be an alternative solution to your problem.
Unfortunately it doesn't helped me much. All variables and segments were already located absolutely (declared in the linker file). I think it would help me only if I could know the guidance logic by determining the order of the imported modules in a LIB. Thus, I could manage the relevant dependecies so that I could get exactly the same C_INITSEG as in BOOT project. Is it possible to get this information?
When you re-create an application and change something on it, then it becomes unlikely that you get exactly the same image again.
You should really consider the alternative methods (using PUBLICSONLY and a reduced STARTUP file) as presented in the Multi-application example.