This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Warning #10229-D When Using a Circle Buffer

Other Parts Discussed in Thread: MSP430FR5739

I am getting the only warning when compiling my code in the MSP430FR5739

#10229-D output section ".data" refers to load symbol "_nop" and hence cannot be compressed; compression "rle" is ignored

Below are the functions for the Circle Buffer.  I have found that when I remove these functions, the warning goes away.  If I can guess, it has something to do with how I am making the CircleBuffer data type.  However, I'm not sure how to fix it.

/*************CIRCULAR BUFFER*************/
typedef struct { unsigned char value; } ElemType;

// Circular buffer object //
typedef struct
{
    int         size;   // maximum number of elements
    int         start;  // index of oldest element
    int         end;    // index at which to write new element
    ElemType   *elems;  // vector of elements
} CircularBuffer;

CircularBuffer cb;
ElemType elem = {0};
int testBufferSize = 0xFFF; // arbitrary size //

void cbInit(CircularBuffer *cb, int size)
{
    cb->size  = size + 1; // include empty elem //
    cb->start = 0;
    cb->end   = 0;
    cb->elems = (ElemType *)calloc(cb->size, sizeof(ElemType));
}

void cbFree(CircularBuffer *cb)
{
    free(cb->elems); // OK if null //
}

int cbIsFull(CircularBuffer *cb) {
    return (cb->end + 1) % cb->size == cb->start; }

int cbIsEmpty(CircularBuffer *cb) {
    return cb->end == cb->start; }

// Write an element, overwriting oldest element if buffer is full. App can
// choose to avoid the overwrite by checking cbIsFull(). //
void cbWrite(CircularBuffer *cb, ElemType *elem) {
    cb->elems[cb->end] = *elem;
    cb->end = (cb->end + 1) % cb->size;
    if (cb->end == cb->start)
        cb->start = (cb->start + 1) % cb->size; // full, overwrite //
}

// Read oldest element. App must ensure !cbIsEmpty() first. //
void cbRead(CircularBuffer *cb, ElemType *elem) {
    *elem = cb->elems[cb->start];
    cb->start = (cb->start + 1) % cb->size;
}

Any suggestions on how I can revise this would be appreciated.  I've already looked into the following two posts:

  • http://e2e.ti.com/support/development_tools/compiler/f/343/p/86954/307716.aspx#307716
  • http://e2e.ti.com/support/development_tools/compiler/f/343/p/247239/864915.aspx


  • The trigger is almost certainly the call to calloc and free.  What linker command file are you using?

  • For the functions free and calloc, I'm using the linker file <stdlib.h>. 

    I'm Using CCS v5.5 and am using the generic compiler from there.  After reading a couple of other forums regarding the issue, I found that I have to alter the compiler so that I can allocate that part of the memory for the buffer.  For my current setup, is there a way I can do this?

  • The include file <stdlib.h> is not part of the linker, it is part of the C library.

    The linker is controlled by the linker command file, which you would not normally need to alter, and which is set for you automatically by CCS.  See the MSP430 Assembly Language Tools User's Guide (SLAU131), section 8.5 "Linker Command Files."  This is where you configure the memory of the device and where sections are placed.

    However, the default linker command file should not lead to the warning you have posted.  I would like to know which linker command file you are using.  You can determine this by going to the build console and looking for the link step.

  • Archaeologist said:
    Language Tools User's Guide (SLAU131), section 8.5 "Linker Command Files." 

    Thank you for the reference.  I was very lost when it came to learning about the linker file.  I'm still reading through it, but I'm sure this will help me get an idea of how this works.

    Archaeologist said:
    I would like to know which linker command file you are using.  You can determine this by going to the build console and looking for the link step.

    Below is the console reading when it builds the program.

    'Finished building: ../main.c'
    ' '
    'Building target: SPI Sniffer FR5739.out'
    'Invoking: MSP430 Linker'
    "C:/ti/ccsv5/tools/compiler/msp430_4.1.7/bin/cl430" -vmspx --abi=eabi -g --advice:power=all --define=__MSP430FR5739__ --diag_warning=225 --display_error_number --diag_wrap=off --silicon_errata=CPU21 --silicon_errata=CPU22 --silicon_errata=CPU40 --printf_support=minimal -z --stack_size=160 -m"SPI Sniffer FR5739.map" --heap_size=160 --use_hw_mpy=F5 -i"C:/ti/ccsv5/ccs_base/msp430/include" -i"C:/ti/ccsv5/tools/compiler/msp430_4.1.7/lib" -i"C:/ti/ccsv5/tools/compiler/msp430_4.1.7/include" -i"C:/ti/ccsv5/ccs_base/msp430/lib" --reread_libs --warn_sections --display_error_number --diag_wrap=off --xml_link_info="SPI Sniffer FR5739_linkInfo.xml" --rom_model -o "SPI Sniffer FR5739.out"  "./main.obj" "./keyg.obj" "./gpio.obj" "./fram.obj" "./cs.obj" "../lnk_msp430fr5739.cmd" -l"libmath.a" -l"libc.a" 
    <Linking>
    warning #10229-D: output section ".data" refers to load symbol "_nop" and hence cannot be compressed; compression "rle" is ignored
    remark #10372-D: (ULP 4.1) Detected uninitialized Port B in this project. Recommend initializing all unused ports to eliminate wasted current consumption on unused pins.
    'Finished building target: SPI Sniffer FR5739.out'
    ' '
    
    **** Build Finished ****
    

    It looks like it is using the generic MSP430 Linker.  However, I'm not sure how else to read this. Do you see anything that would cause this error.  Do you think I should change something in my code or in the linker file to fix this?

  • dauletle said:
    warning #10229-D: output section ".data" refers to load symbol "_nop" and hence cannot be compressed; compression "rle" is ignored

    I am unable to reproduce that diagnostic.  I am using the standard lnk_msp430fr5739.cmd located in ccs_install_root\\ccsv5\ccs_base\msp430\include .  Your linker invocation however, does not get this file from that location.  Instead, it has a project specific copy, referenced with the command line syntax ...

    ../lnk_msp430fr5739.cmd

    My guess is this file is changed from the original, and those changes are causing the problems.

    Thanks and regards,

    -George

  • George Mock said:

    I am using the standard lnk_msp430fr5739.cmd located in ccs_install_root\\ccsv5\ccs_base\msp430\include .  Your linker invocation however, does not get this file from that location.  Instead, it has a project specific copy, referenced with the command line syntax ...

    ../lnk_msp430fr5739.cmd

    My guess is this file is changed from the original, and those changes are causing the problems.

    I thought that since I updated my CCS recently, that this would cause this issue to occur.  That is why I made a new CCS Project, and just copied the code from the previous project.  I also added the library location ccsv5\ccs_base\msp430\include to the library search path in the Project Properties window.  However, I still get the same results.

  • I can reproduce the problem now.  Please ignore my previous post.  It is all wrong.

    To describe the problem, and possible solutions, is beyond the scope of what I can do here.  It quickly gets into arcane details of how compression works in the linker, how GROUP is used in that link command file, etc.  As far as you are concerned, since that link command file is authored by TI, this is all TI's problem.

    The downside of the warning is not that bad.  It just means that the .data section is not as small as it could be.  There are no issues with correctness of execution.  If everything fits in your flash, then I recommend you just ignore it.

    Thanks and regards,

    -George

  • Thank you for looking into the issue.  I appreciate all the help :)