[Dspforum] debugging help.
doug wenstrand
dougwen at gmail.com
Tue Oct 21 18:08:29 MDT 2008
** Yea, I saw that.. Note that in general if you want to do dynamic
allocation of variables, you will need to increase the heap size, which by
default is 0x400 bytes I think ***
Also, You aren't the only one... most of the unexplained errors that people
have had so far are all related to similar things. In fact, it is probably
something I haven't mentioned enough. When the environment crashes, and you
have to restart the emulator it is almost always one of two things : 1)
stack overflow 2) a bad pointer somewhere that writes to memory in a place
that it shouldn't. Certain memory locations have all sorts of side effects
associated with them. Debugging this stuff is difficult, particularly since
the effect is often not seen right away, and it might be different every
time. I sometimes like to just randomly hover around in the debugger and
observe the locations of various variables and see if they make sense.
Viewing the big arrays in the memory view window also is useful.
On Tue, Oct 21, 2008 at 7:23 PM, Pablo Pombo <p_pombo at hotmail.com> wrote:
> Ooppss. Thanks, I guess my only excuse is that I changed back and forth
> between static allocation and dynamic allocation as you can see my commented
> out lines.
> Anyway, thanks a bit embarrasing....
>
> ------------------------------
> Date: Tue, 21 Oct 2008 17:34:01 -0400
> From: dougwen at gmail.com
>
> To: dspforum at echelonembedded.com
> Subject: Re: [Dspforum] debugging help.
>
> 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
>
>
>
> ------------------------------
> Connect to the next generation of MSN Messenger Get it now!
> <http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-us&source=wlmailtagline>
>
> _______________________________________________
> 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/fad4853a/attachment.html>
More information about the Dspforum
mailing list