locating functions automatically

?PR?*?myobject (0XC11200)

all it does is locate the first function and then gives these error messages:

I'm afraid you're mistaken about what that does. If that wild-card does work, it'll locate all the matching sections to that single location. Which, of course, explains why it doesn't work, and also explains the exact error message.

I don't think the Keil tools are prepared to allow the kind of trick you want to pull off. You'll have to name all functions' sections individually in a CODE [BL51] or SEGMENTS [LX51] directive.

if using PK51,

#pragma userclass(code = your_class)

does exactly what you want, if you put all the functions to be combined in the same source file.
The CLASSES linker directive is then used to assign a physical adress range.

Thank you Alex. :) it worked and i was able to locate all my functions in the new class.

I have a new problem now.

I am writing a code patch for code that is already deployed. This means that my new generated object has to be linked with the addresses in the existing code.

Unfortunately, even if i located all my new functions and variables in unused space, the compiler/linker still doesn't generate the same addresses for the old functions.

Comparing the map files, it turns out that the difference started in the size of the
?C?LIB_CODEsegment.

here's a sample from the map files:

original:

800100H   8001FFH   000100H   BYTE   AT..     ECODE          ?PR?C_SYSCALL?SYSCALL
800200H   80023FH   000040H   ---    OFFS..   CODE           ?CO?ACMB4?1
800240H   8003B8H   000179H   BYTE   UNIT     CODE           ?C?LIB_CODE  
8003B9H   800479H   0000C1H   BYTE   UNIT     CODE           ?C_C51STARTUP_MAIN
80047AH   8004D5H   00005CH   BYTE   UNIT     CODE           ?C_INITSEG

patched:

800100H   8001FFH   000100H   BYTE   AT..     ECODE          ?PR?C_SYSCALL?SYSCALL
800200H   80023FH   000040H   ---    OFFS..   CODE           ?CO?ACMB4?1
800240H   8003CFH   000190H   BYTE   UNIT     CODE           ?C?LIB_CODE 
8003D0H   800490H   0000C1H   BYTE   UNIT     CODE           ?C_C51STARTUP_MAIN
800491H   8004ECH   00005CH   BYTE   UNIT     CODE           ?C_INITSEG

Because of this, all other addresses sort of "shifted" down the map.

Is there a way that i can somehow "lock" the original addresses and have the linker simply add/link my new patch code to the original program?

I am writing a code patch for code that is already deployed
if you can get a code patch in, you can get new code in as well. WHY PATCH?

Erik

"if you can get a code patch in, you can get new code in as well. WHY PATCH?"

Well, the original code is in ROM and it's around 80kb. and i only have around 16kb EEPROM for the patch.
I still need the patch to be able to call into the original ROM code. Unfortunately, the linker isn't cooperating...

Any help would be much appreciated.

Well, the original code is in ROM and it's around 80kb. and i only have around 16kb EEPROM for the patch.

And how were you planning on getting that patch code to be called by the ROM image in the first place?

Unfortunately, the linker isn't cooperating...

Well, you didn't exactly ask it to cooperate, did you? So far, you're fighting it. You should be linking the original ROM application into your patch project so all functions already present will be taken from that. The "symbols only" option should help with that.

"And how were you planning on getting that patch code to be called by the ROM image in the first place?"

the rom application was written with a patch in mind. it checks certain addresses in the eeprom to see if there is a patch. if so, it jumps to a predetermined address in eeprom.
This already works and i successfully call into my patch. my problem is the link back. it seems that the compiler/linker determined that i need additional functions in my ?C?LIB_CODE. that's why it grew in size.
Now because of this, my patch code is linked to a differently mapped version of the rom code, not identical to the original.

i'm at home now. will look into the "symbols only" option when i get in tomorrow. Thanks for all the help.

Michael, I am very interested in finding out if you could make it work and how you were able to compile/link new version of patch keeping ROM binary exactly the same. I am guessing you would need to pin-down some patchRAM code/data (directly referenced by the ROM) to original addresses used during ROM tapeout.

I have a very similar requirement for my project.

actually, i wasn't able to make the full patch work. i did a simple workaround by isolating what parts of the patch caused the CLIB to enlarge and excluded them from the build. then i worked with what i had left...

I was pressed for time so that was the best solution.
if you find a better way to do it, please tell me. thanks. :)