[Dspforum] More troubles with lab 6

[Ryan Merton]

Hi Doug,

Your guess was correct in that waitfordma was in fact not waiting for
anything.  Throwing in an arbitrary spin loop allowed for everything
to work.  Then I had it print how many times it sat in it's
theoretical "wait for DMA to finish" loop, and the number is always
zero.

I guess that's what I get for using someone else's code, even if it
was from an example TI provided!

I haven't worked out yet how to correctly wait for it, but I'm sure it
can't be that hard!

Thanks,
Ryan

On Thu, Oct 16, 2008 at 3:36 PM, Wenstrand, Doug S.
<Douglas.Wenstrand at jhuapl.edu> wrote:
>
> Yes, there are some things that we need to do to setup SDRAM, and they
> are in the GEL file, so check to make sure that you are using the gel
> file for the c6713dsk.  CCS sets these registers when you connect the
> emulator, that why we don't in our software.
>
> The reason I don't see that being an issue is that I thought we saw
> beautiful data that you had extracted from SDRAM and put into L2.  Are
> you sure that you are waiting for the DMA transfers to happen correctly?
> If you can step through all cases, and see the right FFT show up in the
> right place in external memory, and only when free-running it goes bad,
> I suspect that the waiting process might not be correct.
>
> Two things :
>
> 1) see how long you actually wait in waitfordma.  If it seems too fast,
> something is wrong.
> 2) send me the project at the website... Lab6_merton_test.zip or
> something like that. I'll take a look as well
>
> Seeya
> Doug
>
>
>
>
>
> ---------------------------------------
> D. S. Wenstrand
> Johns Hopkins University
> Applied Physics Laboratory
> (240) 228-4282
>
>
> -----Original Message-----
> From: dspforum-bounces at echelonembedded.com
> [mailto:dspforum-bounces at echelonembedded.com] On Behalf Of Ryan Merton
> Sent: Thursday, October 16, 2008 3:01 PM
> To: dspforum at echelonembedded.com
> Subject: [Dspforum] More troubles with lab 6
>
> Doug,
>
> Remember how we figured out that my problem last night was related to
> the bit reversal indexing?  It wasn't.  I went home, and I did in fact
> call the routine with the correct parameters to begin with.
> Breakpointing around the FFT and saving data along the way leads me to
> see no problem at all.  Only after I remove the breakpoints and let it
> go freerunning do things start to mess up.
>
> Is there some magic we have to configure to get the SDRAM timings right,
> or DMA configuration registers aside from the QDMA registers?
>
> I breakpointed after bringing the time domain data in from ext ram,
> after the FFT and bit reversal, and after the FFT data is stored off to
> RAM.  At each of those steps for the first 7 FFTs I saved the contents
> of external RAM.  It all looks fine.  I got tired of it, removed the
> breakpoints, and let it run, then dumped it all at the end... and
> starting at about the 13th FFT the FFT data is not right.
> The time domain data remains intact.  If I do the first 3 FFTs and let
> it go free running, it messes up around the 6th or 7th FFT.
>
> Any ideas?  I am using this to wait for the DMA to finish:  while
> (!(EDMA_getPriQStatus() & EDMA_OPT_PRI_HIGH)); I stole that line right
> from the CSL user's guide.  I am tempted to put something like
> for(x=0;x<10000000;x++){blah=sin(x);} and see if it works then.
>
> Thanks,
> Ryan
>
> _______________________________________________
> 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
>