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
As nobody has any idea about your system, or your project, or what's in this "old code ROM" or how you manage to have code in RAM, it is completely impossible to answer that!
I programed my otp rom with a project developed with keil for 8051. later I modified my hw and added ram space for code. the question is how to integrate the opt project (C, Obj, or hex) and integrate it to the new project that uses the new hw ram code space?
what are the step I need to do ?
We still can't answer because you still haven't given enough information.
If the processor already have code in the OTP memory - how will it be able to reach your new code in RAM? And what will copy your code into RAM?
Hi, part of the new Hw there is a patch mechnisem transfring the pc to ram new main(). the new code is downloaed to the ram by external device.
In order to continue using the old code in otp I need to link it to the new code.
hope it clears my problem, any solutions?
And what about the RAM for the variables?
Entry points for the functions and addresses for global variables are trivial to fix. But that isn't enough. The linker did convert lots of local variables into global variables reused between different function calls.
How do you think you'll manage to get that compatible with your new program? All variables for the new RAM-based program must be stored in separate RAM from the data/idata/xdata used by the OTP code.
Why bother to make new hardware with lots of patch hardware? Why not switch processor at the same time?
The new ram uses only new maped variables becaus the old ones are maped to a known adress. basicaly I wanted to add the old code files to the new project and compile them.
The thing is that the new project will convert the old file to a new hex and not what I expected: old hex with new additions.
can I keep the compiler from modify the old code ? even if its less compact ? Is there another way to build this project ?
thanks, 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.