[Dspforum] debugging help.

Tue Oct 21 17:51:40 MDT 2008

I got it.   It was not the allocation of the data main arrays but it was just as bad.    I either have to sleep more or go ask Joe the plumber for a job. (He seems to be doing good) :)

I hope I did not take too much of your time with this 
Date: Tue, 21 Oct 2008 18:54:46 -0400
From: josephhaber at gmail.com
To: dspforum at echelonembedded.com
Subject: Re: [Dspforum] debugging help.

Pablo,

Thanks for the answers to the questions. In addition to Doug's advice, this warning is probably causing a problem:

>> warning: Detected a near (.bss section relative) data reference to the symbol

            _DSK6713_AIC23_codecdatahandle defined in section .far.  The
            reference occurs in
            C:\CCStudio_v3.1\MyProjects\lab6\Debug\c6713dskinit.obj, section
            .text, SPC offset 00000058.  Either make the symbol near data by

            placing it in the .bss section, or make the references to the
            symbol far.  For C/C++ code use 'far' or 'near' modifiers on the
            type definition of the symbol or compile with the --mem_model:data

In fact, we have observed it associated with the xmit function hanging. Somehow one of the references gets screwed up (it even mentions something about codecdatahandle), and your program goes off into space (I haven't figured out the exact mechanism).

You need to change the memory model like the warning tells you. You can do it in the menus, which I can check later tonight (don't have CCS on this machine).

Joseph

On Tue, Oct 21, 2008 at 5:34 PM, doug wenstrand <dougwen at gmail.com> wrote:

Pablo,one of your warnings is a little worrisome, (the vectors section is missing), but I don't think that is your problem.  However, it is easily corrected by changing your linker command file to match the name of the section in the assembly (i.e. linker command calls it "vectors" and the assembly calls it "vecs")

I think your real problem is a pointer one, as all good C problems are.  Note that your interrupt service routine is filling up an array named "data"..  You conscientiously used a pragma to allocate "data" to external ram.  

COMPLEX *data;COMPLEX *out_data;#pragma DATA_SECTION (out_data, ".EXT_RAM");#pragma DATA_SECTION (data, ".EXT_RAM");

However, you never allocated an array, you simply defined a pointer.  So, what this means is :

"data" is of type pointerthat pointer is located at 0x80000000out_data is also of type pointer.that pointer is located at 0x80000004

when you say "data[25] = 123"that means the dsp reads the value at data, uses that as an address, adds 123 locations to it, and sets it.Problem is, that value at 0x80000000 was never set.  that because you actually wanted the data array there.  This will obviously create pretty crazy and unpredictable behavior depending on what the memory location at 0x80000000 happens to be when you power up.

try allocating the array as an actual array : COMPLEX data[NUMSAMPLES];and it should work much better. 
A fringe benefit is that now the linker will actually check to make sure that you have enough space in EXT_RAM to hold your arrays.  For instance if you said : COMPLEX data[5trillion], it would tell you that there is no room in that section.  If stuff is just treated as pointers, you lose that ability.

Doug

On Tue, Oct 21, 2008 at 3:44 PM, Pablo Pombo <p_pombo at hotmail.com> wrote:

1)
It never returns from the copy from SRAM function
It does not stop in a breakpoint within the copy loop.
It does not stop in a breakpoint within the while(1) loop
there is not optimization turned in yet.

2)
My software is codec runs in an interrupt.  It is hanging in that line but it is not polling. I guess the interrupts are generated.
It does not stop in a breakpoint within the while loop.
The play back is my debugging (only when not processing ffts) to verify that I writing to memory correctly.  I read back from SRAM and play it.

I will try blinking an LED

3)
I get a couple of warnings, all of them have been with me from the beginning and the third one in particular goes away with if I change the memory model to all data being far.

>> warning: creating output section .vecs without SECTIONS specification
>> warning: creating .stack section with default size of 400 (hex) words.
   Use
            -stack option to change the default size.

>> warning: Detected a near (.bss section relative) data reference to the symbol
            _DSK6713_AIC23_codecdatahandle defined in section .far.  The
            reference occurs in
            C:\CCStudio_v3.1\MyProjects\lab6\Debug\c6713dskinit.obj, section

            .text, SPC offset 00000058.  Either make the symbol near data by
            placing it in the .bss section, or make the references to the
            symbol far.  For C/C++ code use 'far' or 'near' modifiers on the

            type definition of the symbol or compile with the --mem_model:data

thanks, I will try a couple of things once I am in front of the board again.

Date: Tue, 21 Oct 2008 08:08:53 -0400

From: josephhaber at gmail.com
To: dspforum at echelonembedded.com
Subject: Re: [Dspforum] debugging help.

Pablo,

A couple of questions:

1) What is the observable condition that makes you think your program is not working correctly?

2) Why do you think it dies in the copyData function if you find yourself in the transmit polling? Also, why do you think the while(1) loop is not running? Are you playing something out the codec the entire time? I am wondering if the while(1) is in fact running (you may be blinking and LED, or have a debug statement that makes it clear it is not).

3) Do you get any warnings when you build your project?

Joseph

On Tue, Oct 21, 2008 at 7:03 AM, Pablo Pombo <p_pombo at hotmail.com> wrote:

I am looking for tips here.  

I get all data recorded.  I know the 10 seconds are good because I can play them back. 

I have the fft calculated,  I know is good because I can feed a tone and I get the right response.  

Now in the middle of reading from memory my program goes south 

copyData_from_xram(int j)
{
    for (i = j*(N/2); i <  j*(N/2)+ N ; ++i)
    {
        x[i].re = data[i].re;
        x[i].im = data[i].im;

    }
}

I do not understand why is breaking.  I am not using DMA yet.

When I break it seems to be hanging  in:

 if (poll) while(!MCBSP_xrdy(DSK6713_AIC23_DATAHANDLE));//if ready to transmit
        MCBSP_write(DSK6713_AIC23_DATAHANDLE,AIC_data.uint);//write/output data

And the infinite loop in main does not seem to be running.

Any ideas.  I am a little stuck here.

Explore the seven wonders of the world Learn more!

_______________________________________________

Dspforum mailing list

Dspforum at echelonembedded.com

http://echelonembedded.com/mailman/listinfo/dspforum_echelonembedded.com

Discover the new Windows Vista Learn more!

_______________________________________________

Dspforum mailing list

Dspforum at echelonembedded.com

http://echelonembedded.com/mailman/listinfo/dspforum_echelonembedded.com

_______________________________________________

Dspforum mailing list

Dspforum at echelonembedded.com

http://echelonembedded.com/mailman/listinfo/dspforum_echelonembedded.com

_________________________________________________________________
News, entertainment and everything you care about at Live.com. Get it now!
http://www.live.com/getstarted.aspx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://echelonembedded.com/pipermail/dspforum_echelonembedded.com/attachments/20081021/c137c808/attachment-0001.html>