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
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