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.
Hi, In my project I have some functions that has to be protected against changes. For that reason a checksum has to be calculated on that specific code in runtime, just to prove that the actual code is intact. Those specific functions are built in an own outside project (just to protect it from changes) and downloaded to a dedicated area in the flash. When the standard code wants to access this functionality in the "outside code" an absolute jump is made to the start address of this outside function (0x50000). This seems to go right, in the "outside code" I can set some outputs to light some LEDs, so the jump seems to have gone right. But when I try to use variables in this "outside code" nothing seems to work, I tried to make a while loop to blink a diode and counted a variable down to zero, but the variables seems corrupt. What can be the problem? Can it be something with the memory model that makes references to variables corrupt? I don't know, I'm not so good at memory models. Any Idea, some one ? Regards / Rasmus
I'm don't think I am following you entirely so this may be nonsense. It is fairly common to have code from two projects loaded and running sequentially on same target (boot then application). This is fairly simple because you can run their own startup code and can share data memory, etc. Running code from two projects simulataneously sounds much more difficult and problematic to me. Have you considered making the part of your application that cannot change a library? You can include it in your main project and call the functions directly. You don't have to fool around with merging hex files and shouldn't have to deal with problems you are seeing (which sounds like a memory overlap or addressing problem). Just make sure the library is built with the same memory model as the main application. The library will never change unless you purposly rebuild it. You can also use linker commands to locate it where you like if necessary.
Have you considered making the part of your application that cannot change a library? Do not "consider" it, DO it, is my recommendation. Erik
Erik, I don't understand. Can you pleas explain to me what you mean? What is that library and what part shall not change it, code2, the "outside code"? Regards Rasmus
Erik, Ok, sorry, I didn't se Walter's post. I think I know what you mean but I have to learn more about building libraries I guess. I have to build the "outside code" as a lib and then include it in my standard project, is that right? But… Are you sure that the hex image for the "lib part" won't change when I rebuild the standard project. I mean aren't addresses and things like that defined by the linker, and shouldn't that impact on the hex image. You see, I need the hex image for that part to be unchanged. Thanks Rasmus
Are you sure that the hex image for the "lib part" won't change when I rebuild the standard project. That is my understanding. Do you agree Erik?
Are you sure that the hex image for the "lib part" won't change when I rebuild the standard project. The .lib is NOT hex images You see, I need the hex image for that part to be unchanged. If it does, be ecstatically happy, it is because something in the "other part" (the .objs) made it essential (such as the variable conflict that you started the thread with). However the location may change all the time, but that is totally irrelevant since you bet a standard FULL .hex file just to load. Erik
The 166 architecture has DPP registers to address near memory. In case of two separate application they need to use exactly the same DPP settings. Still I think the best way is to debug the problem yourself using the simulator. You may load the two applications into the simulator using: http://www.keil.com/support/docs/2616.htm Reinhard