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.

Debug stepping problem 6713 DSK

Hello all,

It may turn out this might be better in the code composer forum, but until I've established the exact problem this is probably the best place for it.

I am working with a TMS320C6713 DSK with code composer 4.0.1.

I am working out the average (mean) of two complex numbers, here's a snippet of the C code:

mean1.real = 0.0;
mean1.imag = 0.0;
mean2.real = 0.0;
mean2.imag = 0.0;
for(m=0;m<nblocks;m++)
{
mean1.real = mean1.real + X1[k][m].real;
mean1.imag = mean1.imag + X1[k][m].imag;
mean2.real = mean2.real + X2[k][m].real;
mean2.imag = mean2.imag + X2[k][m].imag;
}
inv_nblocks = 1/(float)nblocks;

mean2.real = mean2.real*inv_nblocks; // Divide by the number of time blocks to obtain average
mean2.imag = mean2.imag*inv_nblocks;
mean1.real = mean1.real*inv_nblocks; // Divide by the number of time blocks to obtain average
mean1.imag = mean1.imag*inv_nblocks;

The problem is that when I run my whole program it gets stuck on this fairly simple bit of code. When stepping through line-by-line it stalls on the line:

inv_nblocks = 1/(float)nblocks;

When I step into this code and then step through the assembly (via the disassembly window), I get the following alert/error:

Considering I am just dividing two numbers this seems pretty weird.

I have three suspicions:

1) Interrupts - somehow an interrupt is occurring that's screwing things up - but I am not sure how to check.

2) Stack overflow - I think I may have ruled this out by setting a breakpoint at the symbol '__stack' as described here: http://processors.wiki.ti.com/index.php/Checking_for_Stack_Overflow

3) Even though I solved the problem in: http://e2e.ti.com/support/dsp/tms320c6000_high_performance_dsps/f/115/t/317936.aspx, which was to do with the instability of an STFT function that I'd written there's chance this could be related (I may have only mitigated the previous problem and not actually solved it fully). At the end of this thread a potential memory problem is discussed, but I don't get the any similar errors this time, see below for the .cmd file that I am using, in case this is an issue. I am using "far aggregate" as my memory model.

Many thanks,
Jack

UPDATE:
I moved the offending line of code elsewhere in my program and it worked, until I stepped through (past the averaging part, as shown above) to another line where there was another divide (/). The debugger went a bit mad and created loads (100+) threads in my debug window, all main() and another unused function. I deleted this other unused function in my code and ran the code again and the code now does exactly what it was doing before except the original offending line is in a different location in my program.


-stack 0x2000
-heap 0x8000

MEMORY
{
IRAM o = 0x00000000 l = 0x00030000 /* 192kB - Internal RAM */
L2RAM o = 0x00030000 l = 0x00010000 /* 64kB - Internal RAM/CACHE */
EMIFCE0 o = 0x80000000 l = 0x01000000 /* SDRAM in 6713 DSK */
}

SECTIONS
{
.EXT_RAM > EMIFCE0
.text > IRAM
.stack > IRAM
.bss > IRAM
.cio > IRAM
.const > IRAM
.data > IRAM
.switch > IRAM
.sysmem > IRAM
.far > EMIFCE0
.args > IRAM
.ppinfo > IRAM
.ppdata > IRAM

/* COFF sections */
.pinit > IRAM
.cinit > IRAM

/* EABI sections */
.binit > IRAM
.init_array > IRAM
.neardata > IRAM
.fardata > IRAM
.rodata > IRAM
.c6xabi.exidx > IRAM
.c6xabi.extab > IRAM
}

  • Hi Jack,

    Thanks for your post.

    When you deal with writing code with floating operands, you should be compliant with both Nr. & Dr. on a fractional data and the variable which is assigned to its fractional part should also align with floating data type. I think, you should use the code as mentioned in the below format:

    inv_nblocks = 1/(float)nblocks; ------------> Wrong

    float inv_nblocks; -----------------> Correct

    inv_nblocks = 1.0/(float)nbloacks ------------> Correct.

    Please use your code in the format mentioned above written in Green.

    Then try to debug your code step by step through the appropriate debugger tool and check whether, you are able to reproduce this issue.

    Thanks & regards,

    Sivaraj K

    ------------------------------------------------------------------------------------------------------- 
    Please click the Verify Answer button on this post if it answers your question.
    -------------------------------------------------------------------------------------------------------
  • Hi Sivaraj K,
    Thank you for the response.

    I'd already realised that this was incorrect and had already changed the offending line to:

     inv_nblocks = 1.0/(float)nblocks;

    The problem still persists, though I noticed if I decrease the stack and heap sizes to 0x800 (in comparison to the values in my cmd file above), my code fails in other areas. Would a divide somehow use up the stack? If this would seem strange if it did.

    Thanks,
    Jack