Hi,
I have a working old code in rom 32k, I added ram code at the upper 32k and I set the hw to start form the new ram at 32k.
I want to address old function from the new ram code without modify the old project.
once I compile the project code the hex output is not the old rom hex with the new ram code.
rather it recompiled the old code to optize it and I have a new hex that is not like the old rom hex with the new additions.
The thinng is that I need to address the old code function (fixed hex in rom).
what can I do?
regards, dan
The chip was developed "long" ago, the patches were debuged and worked "long" ago. this way the otp lasted for "long" and served us well.
we want the same HW with different software to use it in a new project and for that I asked the question.
In order to avoid next gen chip that will cost, there is a simpler option: to try and activate it from ram.
I am aware of the problem and I expected to hear suggestions that I didnt think about..
The question remains the same if I can use the otp rom from ram..
Thanks, dan
And the answer remains the same: if you must ask, you can't.
Seriously. C on a '51 is entirely the wrong platform to pull that kind of stunt on.
If you had been doing this in assembler, and really known what you're doing from the get-go, there might have been a remote chance that this could work. In C, and on the skill level you've exhibited here, it's quite certainly impossible.
On a personal note: "and on the skill level you've exhibited here, it's quite certainly impossible." It seems that not only your not a pro in C and 51, you also missed my experience and deep knowledge in emb systems. Please keep you suggestion for yourself.as your not all people here asking and sharing are beginners.
back on track.. The first option in mind is not to call the old function in rom form C, rather to leave it for assembler, this way the C compiler will leave them as they were..
By changing the location of the ram the compiler will be forced not to link these function and hopefully not to merge them up. since the call will be in asm I can mange the internal variables members, but it looks like a long shot with many misses to handle.
More Ideas?
thanks, dan
How/when do the program jump into RAM? How will the original CRTL copy be initialized? How will all original global variables be initialized? How will you sort out what global addresses to fill with parameter values before you call a function in the OTP?
You are conceptually trying to rewire a kitchen food processor for mixing concrete for a new hospital. Or adding a big-block chevy engine to a normal mountainbike. Or trying water cooling and kevlar strengthening of a couple of bookshelf speakers for use as PA system on a large outdoor event. It's not looking good. Spend a couple of hundred or thousand hours and you will get the idea that the concept is no good.
Of course you will have to play with assembler. But assembler will not be enough, unless the OTP code just happens to have the correct subdivision to allow you to patch in. It most probably does not, since you are trying a reverse of what the OTP code was originally designed for. There is a huge difference between calling a patch function and adding a new program that tries to call back into the original code.
Your hardware is cheap compared to the cost of trying to get a *** solution to work for you. And every time you need to make changes, your *** solution will fail and require you to do more reverse engineering to try to fix it again.
How/when do the program jump into RAM?
there is the clincher.
with an unchanged ROM, that currently does not call the RAM as you have stated "I have a working old code in rom 32k" a) the reset vector will jump to somewhere in the ROM b) the ROM will not call the RAM
so with an unchanged ROM, previously unaware of the RAM it is impossible
Erik
As mentioned above, working in ram and using existing code is a new project to decide on.
The approach is to create a new hex file with only hooks call for used function, then add the lower hex to create a new hex file with both application.
once done, to start going every register used in the old code needed functions and save it un touched, next to update the asm in the new project to fit.
Yes it a long way to do manually and in asm ..
Is there any other creative way to do it ?
In his case, it should be possible, if that original ROM code expected to find code fragments in RAM to replace one or more of the functions in the ROM.
But it is a conceptually large difference between having a fixed program call a couple of replacement functions, and having the replacement functions becomming the new program and try to call back.
With two programs, two sets of global variables must be allocated, given initial values, ...
Next thing is that there will be two sets of CRTL functions for the same operation since the compiler will try to build a new program for stand-alone use. But if there are two copies of the same CRTL function, then there can be huge problems with the state of the two sets of global variables used by the two sets of CRTL functions.
One things leads to another in an every faster spinning spiral of disaster. Somewhere, one or more people thinks they save time/money by following that spiral.
It seems that not only your not a pro in C and 51
You have no idea.
, you also missed my experience and deep knowledge in emb systems.
Given the considerable amount of effort you put into demonstrating you have neither, it's no wonder poeple missed it.
The first option in mind is not to call the old function in rom form C, rather to leave it for assembler
And yet again, you completely misunderstand the problem. The problem is that the old function is written in C, not that it's called from C.
The old code is basically hex/asm/C .. once you know how to call the function in asm its solved. the problem that its a huge asm project with many internal variables to handle on every call.
There must be an essayer way to solve it.
Looking for a way to avoid this compiler resetting the obj, or to find a way to keep the function variables in the old order
"once you know how to call the function in asm its solved."
Repeating the same claim many times doesn't make it true. You are still driving head-first into a meteor storm without any shields. You would already have managed a lot of architecture work on a new design if you hadn't decided to waste time with a lost cause.
Look until you die, but it's the job of the compiler/linker to do what it is intended to do. It is most definitely not designed to scoop out usable code fragments from a completely different application - an application that is mixed assembler/C and that may not be changed but does require lots of global bits and bytes to be in known states to work as expected.
"There must be an easier way" is a dreamers hope to untie the Gordian knot. Yes - the easier way is to ignore our OTP contents, and cut the Gordian knot instead of trying to untie it.
once you know how to call the function in asm its solved.
No, it won't be. And if you really had that "deep knowledge" of C51 you so deftly claimed, you wouldn't need us to tell yo uthat.
There is: It's a bad plan, so don't do it!.
Once you stop banging your head against the wall, it will cease to hurt that much. You might even step far enough back to notice that there's a perfectly working, open door just 5 steps to the right of where you've been trying to pass through a rock-solid wall.
thanks for the brain storming, I will take your advise under consideration.
all the best, dan
if "the old code" as it does not "as is" call anything outside the ROM it is impossible to do what you want without modifying "the old code"
so SPECIFIC questions requiring SPECIFIC answers
a) does "the old code" call anything outside the ROM if no, then b) can you modify "the old code"