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
You can not recompile any old code, for the simple reason that the Keil linker performs some of the code generation. That means that the Keil linker will create code based on the assumption that it can merge the contents of old and new code which isn't true since everything in the OTP are fixed and can't have a single bit changed.
No - you can not keep the compiler+linker from modifying the old code. That is not something the Keil tools are designed for. You can get the Keil tools call functions in the OTP. You can get the Keil linker to avoid the RAM cells already used by the OTP-based code. But you can not have the Keil tools see any of the original source code without getting modified binary data incompatible with the OTP contents.
You still haven't mentioned why you decided to modify existing hardware to push it like this, instead of replacing the processor at the same time, in which case you could have recompiled the source code.
Hi, In your reply: You can get the Keil tools call functions in the OTP. You can get the Keil linker to avoid the RAM cells already used by the OTP-based code
I think calling some rom function from the new ram will be sufficient at this time. What I need to do ?
I already made a project SRC with asm calls to function in ROM but there is the issue of the variables to/from the function and the internal variables used by the function.
how do you thinkI should handle it?
Regards, dan
To be honest, I think you need to hire an expert to look at it for you, and advise you with the benefit of being able to see all your code, all your hardware, and all the other "background" stuff.
Your set up just sounds too complicated to explain adequately on a forum.
http://www.keil.com/condb
In reality, it would take huge amounts of work. What can be done, and what should be done, are two completely different things.
The new program will not know where to place parameters to called functions.
And the program in the OTP flash also expects that the CRTL have been initialized since code in the OTP will call other functions in the OTP and some of these functions may require access to the version of the CRTL stored in the OTP.
But you have _still_ (yes, I understand you don't feel like telling us) not told us why the xxx you have created hardware with this patch capability instead of replacing the processor.
If this had been an original plan, then that original program should have been written with specifically designed stub interfaces for extending the functionality. It doesn't sound like it was, so somehow it sounds like someone have not decided a very bad design choice without first understanding what the decision actually means.
.. "the '51 PC" BIOS in ROM and stored program in RAM.
Many have, over the years, had threads about this (mainly at 8051.oom) I have yet to see a thread ending "it now works great"
Anyhow, even if someone should succeed how many stored program (non-control) apps would there be that fit in 32k or whatever is left after the BIOS?
In the olden pre-ISP days there might have been a reason for an amateur to have such a setup, but with ISP I fail to see the purpose.
Erik
Hi, The device is a chip we developed with rom and available ram for patches. we can add simple patchs to it for fix small problems we deteect using hooks,
The question mentioned is to implimet a new project in the ram and use the old rom function to save code space.
I know that this is an isuue to use the ram, but still I wanted to get tehcnical ideas on how to address it.
Thanks, dan
If "you" developed it, didn't you think about how "you" would use this feature - and test that it actually worked - before committing the chip to production?
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..
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
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