This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Errors and warnings when compiling

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!

Parents Reply Children
  • 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?

    Thanks!

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