Loading a bigger program via Keil Monitor

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.

 Just add money

"I like to simulate the program larger than 8KB"

The only reason for an 8K restriction is if you are using one of the limited versions; eg, the free evaluation or the LPC studio.

If you need to handle bigger programs than the limits of your restricted version, then you just need to buy an unrestricted version.
Simple as that.

Contact Keil sales, or your local distributor:
http://www.keil.com/company/contact.asp?bhcp=1

 RE: Just add money

How to identify the version of Keil tool?

 RE: Just add money

Could u tell me if my produres is ok for a larger program? Please give a reply.

 RE: Just add money

If you want me to take the effort to make a reply, you need to take the effort to type "you" in full - "u" is just being lazy.

 RE: Just add money

Sorry for that. Please give a rely. Thanks.

 Banking

Why do you want to mess about with banking for only 8K?

Would it not just be far easier to choose a chip with sufficient resources for your application?

8K is quite small as 8051s go these days.

http://www.keil.com/dd/search_parm.asp

 RE: Banking

Thanks. For the design, I like to use 89C51 and a EEPROM to implement it and don't know how to use Keil tool to simulate my program. This one is really confued with me because no enough information can be got.

 EEPROM?

Please clarify precisely what you mean by "EEPROM" in this context:

"EEPROM" is usually taken to mean the type of device designed for non-volatile data storage - often with a serial interface.
The key feature of this kind of device is the ability to write individual bytes.

Electrically-Erasable PROMs designed for code storage are usually referred to as "Flash", and usually have a parallel bus interface.

 RE: EEPROM?

"EEPROM" that I meant is what you mention to "flash".
I use 27c512 (64KB) to store the constant data.

 UV-EPROM

"I use 27c512"

That's not even electrically-erasable, is it?

A 27C512 is an old UV-Erasable PROM, isn't it?

ie, you have to put it into a UV eraser before you can re-program it?

 Insufficient Information

"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

 RE: Insufficient Information

Yes, you're right. "89C51" is ATMEL AT89C52. And "EEPROM" is winbond w27c512.

 W27C512

You're right - it is electrically-erasable!

http://www.winbond.com/e-winbondhtm/partner/PDFResult.asp?Pname=349

 RE: W27C512

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?

 RE: W27C512

"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).

 RE: W27C512

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.

 Back to basics

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!

 Storing larger constant data in the external code memory

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.

 RE: Storing larger constant data in the external code memory

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!

 RE: Storing larger constant data in the external code memory

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

 RE: Storing larger constant data in the external code memory

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.

 At last - it begins to make some sense!

"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?

 LCD (Liquid Crystal Display) Bitmap data in external flash

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.

 RE: LCD (Liquid Crystal Display) Bitmap data in external flash

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?

Erik

 RE: LCD (Liquid Crystal Display) Bitmap data in external flash

"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.

 Over simplistic assumption.

"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.