[Dspforum] debugging help.
Joseph Haber
josephhaber at gmail.com
Tue Oct 21 16:54:46 MDT 2008
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 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
>>
>>
>
> _______________________________________________
> 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/1856659f/attachment-0001.html>
More information about the Dspforum
mailing list