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
Ok, I guess I expressed my self badly, let's try again. I have my standard project to build my main application. Then I have some functions that can't be built together with the rest of the code, but they are part of the whole application. For that reason I have build those function in a separate project. When I have built those both projects I merge the hex file from the outside code to the standard code hex file. I use other flash and RAM areas for the "outside code" so it wont be a conflict. When I want to call this functions from the standard code I use a function pointer pointing at address 0x50'000 which is the start address for the outside, stand alone built code. I can jump to this code using the function pointer and set some outputs, but when I start using variables something goes wrong. The variables seem to be corrupt.
I can jump to this code using the function pointer and set some outputs, but when I start using variables something goes wrong. The variables seem to be corrupt. of course, they are. whwn you go between code1 and code2, code1 uses the mamory as its own, then code2 assumes that it is undisturbed HUH? Erik
Erik, I don't have variables that are shared between the two codes. I have exclusively defined a RAM area for the "code 2" that is not used by "code 1" The standard code (code 1) uses RAM space 0x100000 - 0x133FFF and "code 2" uses 0x134000 - 0x137FFF. So when I jump to "code2" and starts executing I have some defined variables in the second RAM space (0x134000 - 0x137FFF). But when I try to access these variables something goes wrong. It seems like it is something with the address references or something… Do you have any idea?
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