We are planning to build a ROM mask + flash environment. That is the lower 32K code space will be mapping to ROM-mask and the upper 32K to flash. The lower 32K will check a function table in the upper 32k (flash). We we put drivers and basic APIs in the ROM-mask which serve as a library (and can't be changed after first release) By updating the flash (upper 32k), we can have different application.
we are planning to build several projects that share the same 32K ROM-mask source code (which is grouped by userclass) and have different application code. But the lower 32k are different.
Is there any solution??
Why? You think you will save money by having a mask-programmed chip? The huge cost of having errors in mask-programmed devices has moved almost all users to pure flash solutions, in which case the availability of mask-programmable devices quite small.
Another thing - your text sometimes suggests that it is the upper half that is mask-programmable, and sometimes that it is the lower half.
An important factor to consider is if your design is fulfilling KISS principle (Keep It Simple, Stupid) - if it doesn't, then you should think twice or trice before continuing. Complicating things tends to affect cost and quality.
en.wikipedia.org/.../KISS_principle
we see this one on a fairly regular basis (invisible fixed code similar to an OS)
my wild guess is that those that propose such a solution are trying to "sell software by the piece"
Erik
Westermark, Thanks for your suggestion and please ignore my last sentence in the starting post.
In my case, we need to have our code running fast and low power consumption. ROM beats flash in these aspects. Updating ROM will be achieved by ECO. But we still want to expand the capability of our firmware in the future. That's why we are planning such a complicated design.
8000-FFFF [APP1] [APP2] [...] ------------------------------------- 0000-7FFF [ROM]
I am just wondering that is it possible to have 2 projects that share the same 'ROM' source code to have the same lower 32K binary???
I have tried to group code into ROM and APP userclass. But the generated binary seems to be different due to different call-tree. Any suggestion??
For high-temperature solutions, ROM is still king. Flash memory retention times drops drastically with high temperature.
If all you need is low power consumption, then it would probably be easier to just look for a different processor. There are a lot of processors that will run very efficiently from a small button cell.
I'm normally using the Keil ARM tools, so you will have to look for help by someone else about how to set up a project. Just note that the linker must know that the fixed part is really fixed. If you just add the common code to the individual projects and compile, then the linker will assume that it may perform optimizations etc for all parts of the code. It is important that the linker knows that the 32kB are locked and that all it has access to is the call addresses. I think this was last discussed in a C51 thread within the last couple of weeks.
I have tried to group code into ROM and APP userclass. But the generated binary seems to be different due to different call-tree. that's the crux, a piece of separate code can not share the call tree with some 'unknown code'
the only way I can see is to modify startup.a51 for the code in high mem not to clear whatever RAM the low code uses and then set the high code to have uninitialized RAM storage in the areas that the low code uses. This is easily accomplished with a small assembler module.
Another problem with your scheme is that, unless you (are ignorant enough to) believe that the low code will never change is that the communication will have to be by indirect pointer call which is not the most efficient use of a '51.
RE low power: TI has some VERY frugal '51 derivatives and so does SILabs (e.g. the '9' series)