[Dspforum] debugging help.
doug wenstrand
dougwen at gmail.com
Tue Oct 21 15:34:01 MDT 2008
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 consciencously 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 pointer
that pointer is located at 0x80000000
out_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!<http://search.msn.com/results.aspx?q=7+wonders+world&mkt=en-US&form=QBRE>
>
> _______________________________________________
> Dspforum mailing list
> Dspforum at echelonembedded.com
> http://echelonembedded.com/mailman/listinfo/dspforum_echelonembedded.com
>
>
>
> ------------------------------
> Discover the new Windows Vista Learn more!<http://search.msn.com/results.aspx?q=windows+vista&mkt=en-US&form=QBRE>
>
> _______________________________________________
> Dspforum mailing list
> Dspforum at echelonembedded.com
> http://echelonembedded.com/mailman/listinfo/dspforum_echelonembedded.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://echelonembedded.com/pipermail/dspforum_echelonembedded.com/attachments/20081021/7043ce68/attachment.html>
More information about the Dspforum
mailing list