• State Not Answered
  • Locked Locked
  • Replies 5 replies
  • Subscribers 22 subscribers
  • Views 1195 views
  • Users 0 members are here
Options
Related
How was your experience today?
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

v6.20 problem?

Andrew Neil

Has anyone else tried C51 v6.20/uVision v2.20?

In one of my 'C' source files with inline assembler, the new Compiler
now creates an empty DATA Segment in the generated assembler. This
causes the Link to fail with Error L109, "Empty Relocatable Segment"

According to the online help & the PDF manual, L109 should not be a
fatal error; the Segment should simply be ignored.

So there are two issues here:
A. Why does the new compiler generate the empty Segment?

B. Why does the BL51 Link fail, when this should not be a Fatal error?
(the behaviour is the same for both the v4.14 & v4.20 Linkers).

  • 0

    I am currently experiencing exactly the same problem. The compiler is adding additional lines to my .a51 file and as you say, the linker is complaining. A temporary (but not good) fix is to remove the unwanted lines. The output file can then be built as normal. Have you had a solution from Keil? I would be grateful if you could pass on any information.

  • 0 in reply to Angus Anderson

    Does anybody have a solution for this Non-fatal error L109 of v6.20. Shall be gratefull, if you could share the information.

  • 0 in reply to Balasekar Katakol

    I have sent this info through to Keil for an answer...

    I am currently using the Keil compiler C51 (V6.23a) and linker BL51 (V4.23).

    I recently upgraded to this version of compiler and linker and am now getting the 'Error L109, "Empty Relocatable Segment"' error on a file that was previously compiling and linking perfectly.

    The Problem:
    I have a file with the following compiler settings selected "Generate Assembler SRC File" & "Assemble SRC File". What I see the problem code being is as follows:

    ****************
static void GenFac (unsigned char xdata *key, unsigned char xdata *fac_ptr) small
{
  unsigned char xdata fac[8];
  unsigned char i=0,j=0;
****************

    This code generates the following empty relocatable segment in the SRC file:

    ****************
?XD?SMGF_Request?REQSMGF           SEGMENT XDATA OVERLAYABLE 
?XD?_GenFac?REQSMGF                     SEGMENT XDATA OVERLAYABLE 
       EXTRN         XDATA (cvt_conversion_error)
...
       RSEG  ?DT?_GenFac?REQSMGF
?_GenFac?BYTE:
       key?040:      DS   2
       fac_ptr?041: DS   2
       fac?042:       DS   8
****************

    This SRC file is created with OT set to 8 but the above problem is still present with OT set to 0. Why does the compiler take the liberties to change the data segment type of the local variable, am I missing something? I am assuming that this is both a compiler & linker problem:
    1) The compiler should not be changing the segment space type of variables (it has no idea about the project's global data space usage &
    2) The linker should pick up on this problem but should not stop linking (i.e. should not be a fatal error)? A warning at the most?

    I have solved this problem for the moment by removing the xdata segment space type from the variable declaration. It work just as well with "data" in place of "xdata" for obvious reasons.

  • 0 in reply to Charles Louw

    I have found the reason for this problem I have been having. I noticed that the function was declared with the directive small (small memory model):

    ****************
static void GenFac (unsigned char xdata *key, unsigned char xdata *fac_ptr) small
****************
    This means that the new compiler is making all the functions local variables "data space variables" as per the functions directive, but the declaration for the variable itself is creating an xdata segment.

    What then did the previous version of the compiler do?
    1) My guess is that it made the variable a data variable and did not create the xdata segment - and did not produce a warning / error that it was doing this?!? The linker would not have been able to pick that up since there was no (empty) xdata segment created...
    2) Alternatively the compiler made the variable xdata? So why only in the new compiler does it abide by these rules?

  • 0 in reply to Charles Louw

    I have a large code settings for my project.
    The following code generated L109 error:

    typedef union tagLONGLONG{
    struct{
    unsigned short hi;
    unsigned long lo;
    } LL;
    unsigned char bytes[6];
    unsigned short words[3];
    } LONGLONG;

    void ZeroLONGLONG(LONGLONG xdata *v)
    {
    v->LL.hi=0; v->LL.lo=0;
    }


    This fix shuts down the error:
    void ZeroLONGLONG(LONGLONG xdata *v)
    {
    char xdata i; //dummy fix
    v->LL.hi=0; v->LL.lo=0;
    }