Hi, I like to simulate the program larger than 8KB via Keil monitor, and separate the functions and constant data and put constant data to a extra eeprom.
The steps I did are as follows. 1. My test board has a eeprom for bank-switching. 2. Genrated 2 hex file, bank 1 and common area. (xxx.hex and xxx.h00) 3. Loading xxx.h00 to the eeprom early. 4. Using "Start the debug session" to start the simulation.
Got a Monitor Error and "illegal write access at CODE address ...etc."
Please give a help. Tks.
"I like to use 89C51"
That is not a full part number!
You need to give the complete part number - including all prefix & suffix letters & numbers; eg
P89C51RA2xx has 8K Flash: http://www.keil.com/dd/chip/3391.htm
P89C51RB2xx has 16K Flash: http://www.keil.com/dd/chip/3214.htm
and there are many more
Yes, you're right. "89C51" is ATMEL AT89C52. And "EEPROM" is winbond w27c512.
You're right - it is electrically-erasable!
www.winbond.com/.../PDFResult.asp
So, you basically have a standard 8051-with-external-CODE-memory system.
You have a full 64K of code memory - there should be no reason to do any cunning tricks to fit your 8K code into this memory! You should have plenty of room!
What exactly are you trying to do?
"You're right - it is electrically-erasable!"
But note that it requires special high voltages (14V and 12V) for erasing and programming.
So this is (probably) not practical for in-system programming.
Modern chips sold as "Flash" (usually) require only the standard power supply (5V, 3V3, or whatever).
About programing w27c512, I did it by another EEPROM programmer not Keil tool early. I don't know if Keil tool can work properly on this situaton while w27c512 is programmed early. Or we need to change the configuration of Keil tool for that.
No problem.
Now - you still need to explain what it is that you're actually trying to do...
Your description so far is just of a perfectly normal, bog-standard, common-or-garden, everyday, vanilla 8051-with-external-CODE-memory system - it should be easy!
Yes. What I want to do is separating the constant data, like the display data, from the larger program and put constant data into external eeprom. I suppose banking switching can help to do it. After doing the above procedure I post, unfortunately, when starting the debug session, the error ocurred again and again, "Illegal write access adress...".
I have no idea for that.
How big is your code (program)?
How big is all your constant data?
If the sum is less than 64K, there is no need to do this!
What I want to do is separating the constant data, like the display data, from the larger program and put constant data into external eeprom. I suppose banking switching can help to do it.
read the linker directives and forget about banking, for 8k code and <56k fixed data (any combo less than 64k) it is a ridiculous approach.
question How do you propose to load the external flash>
Erik
For an idea about storing LCM display data, I propose to use external flash. I think I can have the bitmap data of all screens for a mono LCD in external flash and if some screens need to be modified, I just need to re-program the external flash with the bitmap data of the latest screens. I think the size of code is certainly small than 8k and not sure that the size of display data will smalled than 56k.
"storing LCM display data"
LCM? Do you mean LCD (Liquid Crystal Display)?
" ... bitmap data of all screens for a mono LCD in external flash ... size of code is certainly smaller than 8k and not sure that the size of display data will smaller than 56k."
At last - it begins to make some sense! Wouldn't it have been so much easier if you had explained this in the first place?!
Are you using any XDATA?
If not, why not just map your bitmap data ROM in XDATA space?
Bitmap data is always constant for back-ground display. And if the bitmap data is stored by xdata type, the is required to be initialized every time when the system start-up. I don't think It's a smart way to deal with the bitmap data. I also like to manage the bitmap data in data rom. When bitmap data is stored in data ROM, it's like a data table and it's always over there for look-up. So, it's better that bitmap data is stored in data ROM, the external flash.
Actually, I like to know if Keil monitor can start the debug session by some specific configuration and then access the bitmap data in data rom(I got a illegal access error over here)? Thanks.
If not, why not just map your bitmap data ROM in XDATA space?...
Bitmap data is always constant for back-ground display. And if the bitmap data is stored by xdata type, the is required to be initialized every time when the system start-up.
You can't do that to a ROM mapped as XDATA. How do you propose to write to it?
"And if the bitmap data is stored by xdata type, the is required to be initialized every time when the system start-up."
Not necessarily
Remember, "XDATA" is not synonymous with "RAM" nor even "Volatile memory".
As far as the 8051 is concerned, XDATA is merely a memory address space - your hardware may map RAM into that space, or ROM, or memory-mapped peripherals - or some combination.
"About programing w27c512, I did it by another EEPROM programmer not Keil tool early. I don't know..."
Early, I built a xxx.h00 by bank-switching and download the xxx.h00 in external flash.