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 all,
I have written a patch mechanism which gives the chance to put a new functionality or fix bugs for ROM code.
i am using the kiel microvision 3 v 8.xx and i wrote a small test (2-3 lines of code, 0x20 bytes) patch routine in a seprate c file and compiled it with the source code (located it in EEPROM area by defining user class "ECODE_MytestPatch(....)") and saved/extracted the hex just for the patch code of EEPROM. I loaded that patch on EEPROM with the old ROM hex file (genrated by compiling without test patch code). It was just working fine.
But when i tried a comparatively bigger size of patch(0x40 bytes or around 6 lines of code and 0x10000 byte or 150 lines of code), it gives unexpected behavior i tried to analyze the problem and found following things
1) xdata was increased (I used far keyword and it was shifted to HDATA) 2) CODE segment size was increased (I think this is the problem as in smaller patch code this value dint increase). 3)ECODE_MyTestPatch segment increased (this is the patch code located to EEPROM)
4) some ?L?COMxxx segments appeared in CODE segment.(I think these are genrated because i am using some ROM functions in my patch code but i am not confirmed).
I thought there might be some process/mechanism through which i can only genrate the hex file from patch code without getting touched/changed the ROM hex i.e. only generate the eeprom hex file not regenrate entire ROM hex again.But i cudnot find that.
I have no clue why the code size is increasing. I have no clue how to solve this problem.
Could anybody be so kind to help me on this issue?
Regards Ankit
I haven't done the exact same thing. I've done bootloaders. I've also done embedded scripting, which is one of the ways to allow extending functionality in the field. There are still things I don't understand about your application. Basically, you are trying to split a program in two: the ROM monitor and the EEPROM 'patch'. The fundamental problem is, you are trying to get them to share functions and variables. I'm not sure this can be done with Keil tools. I would approach such a problem in a slightly different way. First of all, I would define an API for communication between the ROM monitor and the EEPROM patch. The API could include memory buffers and function tables in fixed known locations. I would also pay attention to the state of execution environment when passing control to the ROM monitor and the EEPROM patch. When all of that is done, the ROM monitor and the EEPROM patch would be two separate applications built with the standard compiler/linker.
Hay Mike,
Actually this is a smart card OS for which i have written a patch mechanism buil in the OS application.
and now i have to write the patch code and test it.only EEPROM program will be using the Varibles and Functions from ROM but not vice versa. as ROM code just check 1 condition and jump the execution to the particular EEPROM location.
I dont know how to approach now.
thanks