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 a stepped through (past the averaging) 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 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
}