• State Resolved
  • Locked Locked
  • Replies 21 replies
  • Subscribers 52 subscribers
  • Views 2016 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Problems initializing array of float

MikeH
Guru 15580 points

I am having trouble (could me mental issues....:) initializing an array of floating point variables. Here's my code:

float values[16];

for(i=0; i<16; i++) values[i] = 0;

...which sometimes initializes the array to 0.0 and other times initializes 2.030762e-40, which is pretty close to zero :) Why would it not always initialize to 0.0? When it initializes to something other than zero, writing to the array writes an incorrect value.

Can someone provide some guidance on what may be going wrong?

  • 0
    TI__Guru* 84225 points

    I suspect the problem is elsewhere.  That code fragment seems to be fine, so we would need to see a more complete test case.  Can you post a complete, compilable test case that demonstrates the problem?  Be sure to include the command-line options, ISA, and compiler version (not the same as the CCS version).

  • 0 in reply to Archaeologist
    Guru 15580 points

    Arch,

    Archaeologist said:
    Can you post a complete, compilable test case that demonstrates the problem?

    Not easily. I suspect that any simple test case would work fine. In fact, my program works fine much of the time.

    But something is causing the variable array to become corrupted. The initialization is done at the beginning of my main loop. I can start the program from the first line and step through the code line by line while watching the variable get initialized to the wrong number. Is there a register or address that I can watch to see what is going wrong?

  • 0 in reply to MikeH
    TI__Guru* 84225 points

    I need some concrete details before being able to narrow down suggestions.

    How do you know the array contains the wrong value?  Are you looking at it in the watch window?  Are you printing the values from within the program?  Are you using a device with hardware floating-point support?

    Is the problem deterministic for any particular compilation?  You say that for a given compilation, if it displays the error, you can reproduce it 100% of the time?

    Note that for 32-bit IEEE, 2.030762e-40 is a denormal number, which the compiler doesn't support.  I can't guess where this value comes from.

  • 0 in reply to Archaeologist
    Guru 15580 points

    Archaeologist said:
    How do you know the array contains the wrong value?

    From the debug screen below:

    Archaeologist said:
    f it displays the error, you can reproduce it 100% of the time?

    Once the problem has occurred, I can restart the program and step through the code and watch the wrong values appear in the watch window above.

    Archaeologist said:
    Note that for 32-bit IEEE, 2.030762e-40 is a denormal number, which the compiler doesn't support.  I can't guess where this value comes from.

    Nor can I.

  • 0 in reply to MikeH
    TI__Guru* 84225 points

    At the point in time you're seeing these bad values in the watch windows, please take a screenshot of the memory window while it displays the memory at rssi_values (should be 0x19ce@DATA).  Make sure the memory window is in hex mode.

  • 0 in reply to Archaeologist
    TI__Guru* 84225 points

    Also, what device are you using?

  • 0 in reply to MikeH
    TI__Guru* 84225 points

    Okay, those hex values agree with what the watch window is saying.

    Notice the presence of 0x000019CE in the array, which is the address of the start of the array.  This is fishy, and unlikely to be a coincidence.

    Please show me the disassembly of the loop which assigns zeros to rssi_values.

  • 0 in reply to MikeH
    Guru 15580 points

    Arch,

    Any further thoughts on this? I've frozen my development in order to preserve the corrupted state. I'd like to continue debugging when possible.

  • 0 in reply to MikeH
    TI__Guru* 84225 points

    I haven't got enough clues to make a guess yet.  If I had a reproducible test case, I could get to the bottom of it quickly.

    Please show me the disassembly of the loop which assigns zeros to rssi_values.

  • 0 in reply to Archaeologist
    Guru 15580 points

    Archaeologist said:
    Please show me the disassembly of the loop which assigns zeros to rssi_values.

    Sorry, I thought I had already done this....

     Here 'tis.

  • 0 in reply to MikeH
    TI__Guru* 84225 points

    That looks OK, but I need to see the contents of memory location 0x3548 (equivalent to byte address 0x6a90)

  • 0 in reply to Archaeologist
    TI__Guru* 84225 points

    Also please verify that ST1_CPL=1 and ST2_ARMS=1 during that loop.

  • 0 in reply to Archaeologist
    Guru 15580 points

    Is this what you need?

  • 0 in reply to MikeH
    TI__Guru* 84225 points

    That shows that CPL and ARMS are set correctly.

    However, that's not the address I need to see.  I need to see data address 0x3548. 

    On C55x, data addresses have word granularity but code addresses have byte granularity.  Thus, data address 0x1000 is the same location as code address 0x2000

  • 0 in reply to MikeH
    Guru 15580 points

    Ok. How about this. I included a few bytes before 0x3548 since there appears to be multiple C$FL1 designations.

  • 0 in reply to MikeH
    TI__Guru* 84225 points

    That's the stuff.  The good news is that I no longer suspect a heretofore unknown silicon errata; the bad news is that I still don't know the origin of the problem.

    C$FLn is where the compiler is supposed to store floating-point constants.   The compiler doesn't embed floating-point constants in the .text section; instead it places them in a special float constant table, and loads them when needed.  Each C module gets the same names, starting with C$FL1; what you're seeing is the concatenation of float constant tables from 6 different C modules.

    The problem is that most of the values in the float const tables you show are bogus.  The only ones that are reasonable are 0000 0000 (0.0), 431f 85b4 (1.595223e+02), and 3d02 ae3f  (3.19044e-02).  Something is corrupting this table.

    ... I just had a sudden brainstorm: you've got stack overflow.

    Notice the value at 0x3546 (0000 19CE), which is the same as the bogus value that ended up in rssi_values elements 1 through 17, which happens to be the address of rssi_values.  Notice that this value shows up repeatedly in the stack, which starts at address 0x3562.  Typically, any non-uniform value at the extreme end of _stack indicates that some function actually used that part of the stack.  In C55x, the stack grows toward 0, so the clues suggest that your call stack depth grew so large that you overflowed the size of the stack and clobbered the float constant table. 

    Try making the stack much larger and trying again.

  • 0 in reply to Archaeologist
    Guru 15580 points

    Archaeologist said:
    so the clues suggest that your call stack depth grew so large that you overflowed the size of the stack and clobbered the float constant table. 

    Sound likely since I am in the middle of a recurring channel scan with this code. Although, my stacks are already 8kbytes, so is it more likely a memory leak?

    -stack 0x2000
    -sysstack 0x2000

  • 0 in reply to MikeH
    TI__Guru* 84225 points

    I don't think it's a memory "leak"; that usually means dynamically-allocated memory which got allocated and never returned to the free list.  The typical symptom there is that malloc will return NULL, and if the program doesn't check for a NULL return value, you'll scribble on the control registers at address 0x0, quickly causing a crash.

    The typical failure mode for stack overflow is that whatever data is before the stack in memory will get clobbered, which might go undetected for many cycles.  The pattern of values in the float const table and top of the stack that you show in the screen capture strongly suggest stack overflow.

    Sizes in the linker are in terms of bytes, so 0x2000 means 0x2000 8-bit units, which is probably much less than you expect.  You shouldn't count sysstack size, it is sparsely-populated.

    0x2000 8-bit units can get eaten up very quickly if you have just a few modestly-sized function-local arrays, or if you have runaway recursion.

  • 0 in reply to Archaeologist
    Guru 15580 points

    Archaeologist said:
    Sizes in the linker are in terms of bytes, so 0x2000 means 0x2000 8-bit units, which is probably much less than you expect

    Duh...forgot abut that.

    Archaeologist said:
    0x2000 8-bit units can get eaten up very quickly if you have just a few modestly-sized function-local arrays, or if you have runaway recursion.

    ..which I do. 

    I'll expand the stack and try to break it again. Unfortunately, this was a sporadic failure which will be hard to recreate. I'll give it a shot and let you know if it happens again.

    THANKS FOR THE GREAT SUPPORT!

  • 0 in reply to MikeH
    Guru 15580 points

    or if you have runaway recursion.

    Bingo! I had inadvertently created a recursion loop that would occasionally chew up all of my stack!

    Thanks again for the support!