• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 99 subscribers
  • Views 549 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TI 6713 hangs/stalls when debugging code - code stability problem

Jack Harris1
Prodigy 180 points

Hello all,

I am using a 6713 DSK. This question is partially to do with my previous post here: 
http://e2e.ti.com/support/dsp/tms320c6000_high_performance_dsps/f/115/p/317406/1105159.aspx#1105159

The code I am working has the following format:

stft_function(); // Short time Fourier transform

stft_function(); // Short time Fourier transform

for(k=0;k<nfreq;k++) // Loop around and perform some preprocessing on each frequency bin

{

// processing here takes some time - but completes within a few seconds

}

for(iter=0;iter<maxiter;iter++) // Main processing loop

{

// Some code here

}

// Test to see if the code has completed running goes here!

My problem is when I include some sort of test to verify if my code has completed (for example an LED turning on), the code seems to get stuck in the STFT function or within the preprocessing loop. Without a check at the end I can run the code to the end of the first iteration of the main loop, then for a few iterations afterwards (I've ran it to about the 50th iteration, but this loop has a maximum of 1000 iterations).

Why would a piece of code get stuck just because I add some extra code?

I've stepped through the code when it's been stuck in the STFT function and it fails because one of the loop indexes suddenly changes, seems like something is corrupting it. 

I am not expected someone to solve my problem completely but it would be helpful if I was pointed in the right direction,


Many thanks,
Jack

  • 0
    TI__Guru*** 125430 points

    Are you using a dsplib function or perhaps your own hand-written assembly code in that STFT function?  See section B.3 of the dsplib user guide for known issues.  There are some interruptibility issues in dsplib requiring you to disable interrupts around a bunch of functions.

  • 0
    TI__Mastermind 35645 points

    Hi Jack,

    Thanks for your post.

    Is your STFT library call is TI based code or your custom code? If it's your own version, in what way, have you implemented STFT and through which references?

    Could you please share the STFT library source code? So that, it would be possible for us to look into the insight of the issue and to ensure in the right direction.

    In my opinion, the extra piece of code which you have added shouldn't impack the loop iterations of the main function. It might be something else, which we need to look into the source of STFT function mapped in the code. In general, as you specify, loop index should not change from time to time, if it is not consistently holding the values of proper loop indexes, then it might be messing up with the inputs of STFT function else, any dependant function arguments from the main call.

    Thanks & regards,

    Sivaraj K

    ------------------------------------------------------------------------------------------------------- 
    Please click the Verify Answer button on this post if it answers your question.
    -------------------------------------------------------------------------------------------------------
     
  • 0 in reply to Sivaraj Kuppuraj
    Prodigy 180 points

    Thanks for the replies.

    I've attached my (now old) STFT code, the version I am working on at the moment basically swaps my custom 'jack_fft' function (which is almost identical to fft example program in Chassaing's book) with the DSPLIB function DSPF_sp_cfftr4_dif.

    You'll see another problem with this code is that it's restricted to an FFT length of 128, if I change it to anything larger the code is very unstable.

    Using a library version of the FFT as I've done clearly looks like the way forward. Though this leads me to new problem, when using DSPF_sp_cfftr4_dif, I get two new warnings:


    relocation to symbol ".bss" overflowed; the 18-bit relocated address 0x18270 is too large to encode in the 16-bit signed field (type = 'R_C60S16' (87), file = "./cfftr4_dif.obj", offset = 0x0000000c, section = ".text")


    relocation to symbol ".bss" overflowed; the 18-bit relocated address 0x18270 is too large to encode in the 16-bit signed field (type = 'R_C60S16' (87), file = "./cfftr4_dif.obj", offset = 0x000003f0, section = ".text")

    I've flowed the instructions on: http://processors.wiki.ti.com/index.php/Relocation_Overflow_Error with no luck, I've turned trampolines on as well.

    So now I seem to have two problems in parallel !

    Thanks,
    Jack

    1067.stft_old.h

  • 0 in reply to Jack Harris1
    TI__Guru*** 125430 points

    Jack Harris1 said:
    I've attached my (now old) STFT code, the version I am working on at the moment basically swaps my custom 'jack_fft' function (which is almost identical to fft example program in Chassaing's book) with the DSPLIB function DSPF_sp_cfftr4_dif.

    I searched back through some old archives.  There's a bug in this function related to improper handling of interrupts!  This one apparently slipped through the cracks and is not mentioned in Section B.3 (though it should be!).

    You have two options to fix the code itself:

    1. Include the asm file directly in your project and make the correction.
    2. Disable interrupts before calling this function and restore interrupts after you return.

    Here's the issue in the function:

    _DSPF_sp_cfftr4_dif:
           MVC    .S2     IRP,        B0
    ||     SUBAW  .D2     B15,        20,       B15
    ||     B      .S1     no_int                          ; disable interrupts       

           STW    .D2     B0,         *B15[0]
    ||     MVC    .S2     CSR,        B0

           ZERO   .D1     A3                              ; i1 = 0
    ||     SHR    .S2X    A6,         1,        B0        ; n2b = n >> 1
    ||     STW    .D2     B0,         *B15[1]
    ||     AND    .L2     B0,         -1,       B1        ; disable interrupts  <-- Change '-1' to '-2' !!!
    ||     MV     .S1X    B15,        A9   
          
           MV     .D1     A4,         A5                  ; ptr_y0 = ptr_x0
    ||     MV     .L1X    B0,         A0                  ; n2 = n2b
    ||     MV     .L2X    A6,         B2                  ; icntr = n
    ||     MVC    .S2     B1,         CSR
    ||     ADD    .D2     B4,         4,        B6        ; ptr_w1 = w + 4

    Jack Harris1 said:
    You'll see another problem with this code is that it's restricted to an FFT length of 128, if I change it to anything larger the code is very unstable.

    No, this code needs to be <=16k.  Where did 128 come from?  Since this is a radix 4 FFT your input must be a power of 4, i.e. 64 and 256 are valid sizes but 128 is not.

    Jack Harris1 said:
    relocation to symbol ".bss" overflowed; the 18-bit relocated address 0x18270 is too large to encode in the 16-bit signed field (type = 'R_C60S16' (87), file = "./cfftr4_dif.obj", offset = 0x0000000c, section = ".text")

    The .bss section is where global variables are stored.  You apparently have more than 32 KB which is very unusual.  By default the memory model uses "far aggregate" which places all structures and arrays into far memory since those are usually the "big ones".  Normally everything else fits into 32KB.  Is there something you're doing that's making .bss so large? You might start a separate thread for that one in the compiler forum as this particular thread is overflowing with stuff going on.


    Going back to your original issue of instability, the lack of proper interrupt protection in DSPF_sp_cfftr4_dif would most definitely cause the type of instability you describe.  And adding/removing code might shift the timing of interrupts where you do or don't see the issue more frequently.  So once you can actually get it built I think fixing the interrupt issue with that function should resolve your issue.

  • 0 in reply to Brad Griffis
    Prodigy 180 points

    Thanks for the help Brad,

    I seems that I've fixed my problem of an unstable STFT function, I am now using the same code that I posted in a previous post except that I've changed my custom radix 2 FFT function with DSPF_sp_cfftr4_dif from DSPLIB, but included it in my project as an asm file with the change you suggested above.

    Brad Griffis said:

    You'll see another problem with this code is that it's restricted to an FFT length of 128, if I change it to anything larger the code is very unstable.

    No, this code needs to be <=16k.  Where did 128 come from?  Since this is a radix 4 FFT your input must be a power of 4, i.e. 64 and 256 are valid sizes but 128 is not.

    [/quote]

    My custom FFT function was a radix 2 FFT algorithm (which was very flakey to say the least). Now changed the length 1024 with a radix 4 algorithm from DSPLIB.

    Brad Griffis said:
    The .bss section is where global variables are stored.  You apparently have more than 32 KB which is very unusual.  By default the memory model uses "far aggregate" which places all structures and arrays into far memory since those are usually the "big ones".  Normally everything else fits into 32KB.  Is there something you're doing that's making .bss so large? You might start a separate thread for that one in the compiler forum as this particular thread is overflowing with stuff going on.


    Though I've solved my initial problem, I still have instability issues, and I suspect this could be the problem along with a few other things, I'll start a new thread.