Hi Jeff,
The design is to store the McBSP in the external
SDRAM. I increased the EDMA queue length to maxmum
value, it does not help too much. But if I store the
data to onchip memory and it works fine. So it looks
like the bottle neck is in the SDRAM access.
The SDRAM is running at CPU clock/6 =
720/6 = 120MHz clock with 64 bit bus width. At 8Mbps
clock rate, every 1us, 6 EDMA accesses(8bits width) to
SDRAM happen at almost the same time, it should take
6/120M = 1/20us, plus the overhead setup/hold time,
should it be enough time to move the data? There is
no other access to SDRAM in my test.
But for sure I need DSP and host to access SDRAM in
the real product, this will make it even worse. So
how can I resolve this issue? Maybe I can trigger the
EDMA channel every 32bits, but that require a lot of
DSP time pack/repack the channel data. Any suggestion?
Thanks,
William
--- Jeff Brower <jbrower@jbro...> wrote:
> William-
>
> > Each McBSP connects to one local stream of the
> H.110
> > framer chip. 128 channels per stream frame when
> runnig
> > at 8M clock.
> >
> > I think I found the cause. It is related to EDMA
> > performance. Initially I only use one EDMA
> transfer
> > request queue (Urgent quene, whose queue length is
> > only 2 ) by setting the priority to urgent to all
> the
> > six edma channels, this overruns the urgent queue.
> > After I seperate the EDMA channels to use
> different
> > queue( use different priority, high, medium,low,
> for
> > each pair of the EDMA channels), there is no error
> in
> > the first and second McBSP port, but still there
> are
> > some errors in the third McBSP, the error rate is
> much
> > smaller.
> >
> > Just wonder why the EDMA channels serving the
> third
> > port still overran... the default queue is 2 at
> least
> > which should be enough for TX and RX on one serial
> > port. I'll try to increase the queue length.
> Anybody
> > met the same issue before?
>
> One guess would be that you have all serial port
> buffers ready with data at the same
> time, forcing 3 DMA channels to move 6 words in the
> time it takes for the next word
> to shift in (about 1 usec). That sounds like more
> than enough time, but 166 nsec per
> word might still be borderline, as peripheral access
> (mem-mapped register) is not
> nearly as fast as core/onchip mem access. Plus, if
> you have other code running that
> uses internal data busses and the DMA channels have
> to wait...
>
> Where are you DMA'ing to? For test purposes maybe
> try pointing to dedicated onchip
> memory locations and make sure no other code is
> running.
>
> -Jeff
>
> > --- Jeff Brower <jbrower@jbro...> wrote:
> > > William-
> > >
> > > It sounds like you have all three McBSPs
> > > *physically* tied together -- do you? If so
> > > are u using TDM mode?
> > >
> > > How many channels on the framer stream? 128?
> > >
> > > -Jeff
> > >
> > >
> > > William Zhang wrote:
> > > >
> > > > Hi,
> > > >
> > > > I am developing a new board utilizing TI's
> C6415
> > > chip
> > > > and H.110 Framer. I have some troubles with
> the
> > > McBSP
> > > > port when the the serial port is running at
> 8M.
> > > >
> > > > Basically all the three McBSP ports connect to
> the
> > > > local stream of the H.110 Framer, the serial
> port
> > > > clock and frame is synchronized to the
> external
> > > clock
> > > > and frame signal from the framer. I use the
> EDMA
> > > to
> > > > move the data between the serial port and DSP
> > > memory.
> > > > The code and hardware connection between DSP
> and
> > > H.110
> > > > Framer is pretty much same as the TI's
> application
> > > > notes for McBSP and ST-BUS connection guide.
> > > >
> > > > It works perfectly when I set the framer local
> > > stream
> > > > to 4M, I can connect first 32 channels to the
> last
> > > 32
> > > > channels on each McBSP and verify the data.
> > > Howerver
> > > >
> > > > when I set the framer local stream to 8M, the
> DSP
> > > > seems to loose synchronization with framer. I
> got
> > > a
> > > > lot of repetitive datas and sometimes lost
> datas
> > > on
> > > > all of the three McBSP. The firs serial port
> is
> > > > almost clean but the second and third McBSP
> has
> > > huge
> > > > errors. I looked at the XSYNCERR and RSYNCERR
> > > bits in
> > > >
> > > > SPCR regs, there is no errors for each port.
> > > >
> > > > Actually we have another board with C6415 but
> > > > different H.110 Framer, I got the same
> results, 2M
> > > and
> > > >
> > > > 4M work fine but 8M does not work.
> > > >
> > > > So it seems to me more like a problem in the
> DSP.
> > > Is
> > > > there any special consideration to control the
> > > serial
> > > > port for 8M clock when you use external clock
> and
> > > > frame to drive the McBSP? I checked peripheral
> > > guide
> > > > and app notes for the McBSP, did not see
> anything
> > > > special for 8M. Do you have any idea why it
> does
> > > not
> > > > work?
> > > >
> > > > Thank you in advance!
> > > >
> > > > BR,
> > > > William
> > >
> >
> >
> > __________________________________
>
> c6x-unsubscribe@c6x-...
Yahoo! Mail
Stay connected, organized, and protected. Take the tour:
http://tour.mail.yahoo.com/mailtour.html