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
Do I understand this correctly - you really are trying to patch a binary image? That would be too troublesome with the standard tools, as you are beginning to discover. The standard approach is to have a bootloader and to update the whole firmware when necessary. But binary patching is not impossible. For example, there is a company (Ksplice) that provides the service of patching a running linux kernel. But it's not easy, you have to jump through many hoops. You'll only want to do it when you _really_ have to.
Hi I already have a mechanism to jump to EEPROM code in my ROM code. but the oly problem is the compilation and linking which leads to increase the rom code size. and that causes the EEPROM code did not execute along with the old ROM. (may be because of the fact that the linking is according to the new ROM genrated alongwith the patch code and the function addresses in new and old ROM are diffrent).
may be because of the fact that the linking is according to the new ROM genrated alongwith the patch code and the function addresses in new and old ROM are diffrent
When source code changes, you should expect that the linker will change locations of all functions and variables in unpredictable ways. That's the problem with binary patching. So why would you want to do it? What's wrong with traditional firmware update?
Hi I am using NXP's 8051 microcontroller P5CC037. and that is the only way i used to do it or you can say i know. As per my understanding. I have a resident rom code may be you can say it a boot loader it can jump the execution to some predefined EEPROM address on a certain condition (might be flag is set) now at this particular location we can download the code later if we need to change the functionality.
above is what i am doing and i dont know how it is diffrent from firmware update.
Hay Mike,
I googled on this and found diractive PUBLICSONLY. I think it can help me to compile my code the way i want i still m looking how to use this with IDE as we need to include linker output files rather than .h and .c.
but i m still not sure that it cud work..
have you ever used this?
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.
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