Hi, I'm programming for a Cypress EZ-USB FX2 platform, and I'm adding onto the default firmware. I'm having some problems compiling some code, and I'm wondering if I'm running into space limitations already.
First of all, I get warnings when I try to initialize the I2C interface by calling
EZUSB_InitI2C();
I get the warning message
*** WARNING L16: UNCALLED FUNCTION, IGNORED FOR OVERLAY PROCESS NAME: _EZUSB_WAITFOREEPROMWRITE/I2C *** WARNING L16: UNCALLED FUNCTION, IGNORED FOR OVERLAY PROCESS NAME: _EZUSB_WRITEI2C_?I2C *** WARNING L16: UNCALLED FUNCTION, IGNORED FOR OVERLAY PROCESS NAME: _EZUSB_READI2C_?I2C Program Size: data=112.4 xdata=6830 const=216 code=8870
Next, when I try to add in another for loop as below
for (i=0;i<16;i++) EZUSB_ReadI2C(ZTBL_ADDR+i, 0x01, z_table[i]);
I am unable to compile. I get the following error messages on top of the warning message
*** ERROR L107: ADDRESS SPACE OVERFLOW SPACE: CODE SEGMENT: ?L?COM001A LENGTH: 00000BH *** ERROR L107: ADDRESS SPACE OVERFLOW SPACE: CODE SEGMENT: ?L?COM0022 LENGTH: 000009H *** ERROR L138: CODE GENERATION: PROBLEM WHEN PROCESSING INSTRUCTIONS CAUSE: JUMP TARGET OUT OF RANGE ADDRESS: 0750H *** ERROR L138: CODE GENERATION: PROBLEM WHEN PROCESSING INSTRUCTIONS CAUSE: JUMP TARGET OUT OF RANGE ADDRESS: 0761H *** ERROR L138: CODE GENERATION: PROBLEM WHEN PROCESSING INSTRUCTIONS CAUSE: JUMP TARGET OUT OF RANGE ADDRESS: 0785H *** ERROR L138: CODE GENERATION: PROBLEM WHEN PROCESSING INSTRUCTIONS CAUSE: JUMP TARGET OUT OF RANGE ADDRESS: 07B0H Program Size: data=112.4 xdata=6830 const=216 code=8993 Target not created
Have I run out of space already?
Thanks!
See: http://www.keil.com/product/devproc.asp?t=c51&h=1
Program Size: data=112.4 xdata=6830 const=216 code=8870
That tells you how much CODE space you are using.
How much code space do you have? And, more importantly, how much have you configured for your project?
"I am unable to compile."
The messages you show are from the Linker - not the compiler; again, see: http://www.keil.com/product/devproc.asp?t=c51&h=1
"Have I run out of space already?"
Yes, that is what "Address space Overflow" means!
http://www.keil.com/support/man/docs/bl51/bl51_l107.htm http://www.keil.com/support/man/docs/lx51/lx51_l107.htm
Yes I sorta figured that out after reading some more. This is my first time working with the Cypress/Keil platform so please bear with me.
I have in fact read the 1st overflow link, as well as this one- http://www.keil.com/support/docs/1481.htm which tells me to either reduce my code size(gonna be tough) or increase the XDATA/CODE spaces.
The chip I'm using(CY7C68013) has 16KB internal RAM. How can I increase the XDATA/CODE spaces? I read this link - http://www.keil.com/support/docs/1450.htm but still don't know where to change the values(which file or menu dialog?) I'm using µVision2 and under View->Options I couldn't find any "Target" page. I only see 3 tabs - Editor, Colors & Fonts and Shortcut Keys.
Are there also any compiler optimization flags that I can set to optimize for code size? If so where can I change them?
"This is my first time working with the Cypress/Keil platform"
So start here: http://www.keil.com/support/man/docs/uv3/
And, in particular, here: http://www.keil.com/support/man/docs/uv3/uv3_examples.htm
"The chip I'm using(CY7C68013) has 16KB internal RAM. How can I increase the XDATA/CODE spaces?"
Do you understand the distinction between CODE and XDATA in the 8051 architecture?
Does this chip allow that 16K of RAM to be used as CODE space?
"still don't know where to change the values(which file or menu dialog?)"
So start here: http://www.keil.com/support/man/docs/uv3/uv3_examples.htm - it walks you through the whole process of creating a project, setting options, and debugging...
I've managed to find the Target page, but code rom size is already set to "Large:64K program", while memory model is set to "Small: variable in DATA". I also managed to find the individual file's optimization settings and set them all to optimize for size, but that didn't buy me a lot either...
One thing I've noticed is that the EZUSB I2C functions take up a lot of memory. Just by commenting out these functions I save a few hundred bytes. When I then try to uncomment the EZUSB_InitI2C(), it adds like 500+ bytes to the code size. I couldn't find the definition to these library functions either. Will I be forced to do the I2C setup/transfer manually by setting the control registers in order to get it down to size?
"I've managed to find the Target page, but code rom size is already set to 'Large:64K program'"
Look that up in the online help - it's not actually telling the tools what size of physical code space you're using!
Again, you really need to start with http://www.keil.com/support/man/docs/uv3/uv3_examples.htm
OK, I've read the online help regarding code size, and LARGE seems to simply mean that all available space is used, up to 64K, assuming the chip supports 64KB. Since my chip only has 16K, of which only 8K is used for code space, I'm pretty much limited to 8K, which means I pretty much have to find a way to stick within that limit...gonna be tough since the default firmware already takes up 6+K, and just calling the EZUSB_InitI2C() function is already 500 bytes...
I've looked at the examples, they show how to use the uvision3 IDE. I have uvision2 instead, and while I've not used uvision before, I have used other IDEs, so I'm picking up along the way. I don't think I need a "Hello World" example to learn the IDE.
You have earlier said that your chip has 16kB RAM.
Now, you say that it has 16kB of which only 8kB is used for code space.
You do realize that the 16kB RAM are complete separate from your code space.
To be honest I'm not 100% sure. There seems to be 2 modes that the chip can operate at. I quote from the datasheet
3.9.2 Internal Code Memory, EA = 0 This mode implements the internal eight-kbyte block of RAM (starting at 0) as combined code and data memory. When external RAM or ROM is added, the external read and write strobes are suppressed for memory spaces that exist inside the chip. This allows the user to connect a 64-kbyte memory without requiring address decodes to keep clear of internal memory spaces. Only the internal eight kbytes and scratch pad 0.5 kbytes RAM spaces have the following access: • USB download • USB upload • Setup data pointer • I2C-compatible interface boot load. 3.9.3 External Code Memory, EA = 1 The bottom eight kbytes of program memory is external, and therefore the bottom eight kbytes of internal RAM is accessible only as data memory.
The default firmware uses EA = 1.
Anyway, is there any reason why calling a simple I2C init function would make the code ballon by over 500 bytes? It doesn't make sense to me...
"You do realize that the 16kB RAM are complete separate from your code space."
Are you sure that this applies to this particular chip?
It is a common mistake to assume that "RAM" and "XDATA" are synonymous - but they're not!
I don't know this chip in detail but, from what little I do know, I suspect that it may well be able to map its RAM into CODE space...
"is there any reason why calling a simple I2C init function would make the code ballon by over 500 bytes?"
How do you know that it is "simple"...?
"It is a common mistake to assume that 'RAM' and 'XDATA' are synonymous"
See my post, "8051/8052 Memory Architecture" in this thread: http://www.keil.com/forum/docs/thread10634.asp
Thanks for the 8052.com link Andy, I was trying to find an article that details the memory hierarchy of 8051 MCUs.
Anyway, I guess there's not much I can do to solve my problem is there? Would it be possible to add external memory to increase code space?
Interesting concept. I stand corrected :)
"I was trying to find an article that details the memory hierarchy of 8051 MCUs."
That would be the so-called "bible" for the 8051:
Chapter 1 - 80C51 Family Architecture: www.nxp.com/.../80C51_FAM_ARCH_1.pdf
Chapter 2 - 80C51 Family Programmer's Guide and Instruction Set: www.nxp.com/.../80C51_FAM_PROG_GUIDE_1.pdf
Chapter 3 - 80C51 Family Hardware Description: www.nxp.com/.../80C51_FAM_HARDWARE_1.pdf
You would have to consult the chip's Datasheet for the answer to that...