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
Discover Yahoo!
Have fun online with music videos, cool games, IM and more. Check it out!
http://discover.yahoo.com/online.html
Trouble with McBSP running at 8M on C6415
Started by ●May 17, 2005
Reply by ●May 17, 20052005-05-17
Hello William,
I assume that you have checked the signal integrity and circuit
layout...
What type of chip are you using to transmit/receive the signals??
Are you using any special termination and/or routing??
I haven't personally done any designs over 5Mhz, but i am pretty sure
that it can run in double digits.
,mikedunn
William Zhang <z...@yahoo.com> wrote:
William Zhang <z...@yahoo.com> 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
Discover Yahoo!
Have fun online with music videos, cool games, IM and more. Check it out!
http://discover.yahoo.com/online.html
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/c6x/
<*> To unsubscribe from this group, send an email to:
c...@yahoogroups.com
<*
Reply by ●May 17, 20052005-05-17
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
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
Reply by ●May 18, 20052005-05-18
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
> > __________________________________
>
> 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
> > __________________________________
>
Reply by ●May 18, 20052005-05-18
Thanks a lot for your idea, I didn\\\'t know this tool,
now I will read the documentation provided from ADI.
Thanks again for your hint.
Talking about the other question that I posted in fact
you re right, my question should be "how to understand
how good is the assembler code produced by the
compiler", but my english is not so good..
Thanks again
Giovanni --- Jaime Andres Aranguren Cardona
<jaime_aranguren@jaim...> ha scritto:
> Giovanni,
>
> Try to read on PGO (Profile Guided Optimization). As
> I
> undertand it, it is a means to gather information at
> runtime from the execution of the program, which can
> be used to help the compiler to produce more
> efficient
> code. regarding this topic, I\\\'d expect to exist some
> documntation on your original question: "How to
> understand assembler", or better said, "how to
> understand what the compiler did to produce that
> assembly code". Another question, is "how to
> understand how good is the assembler code produced y
> the compiler"
>
> Rgards,
>
> JaaC
>
> --- Mike Rosing <eresrch@eres...> wrote:
> > On Tue, 17 May 2005, Giovanni Parodi wrote:
> >
> > > Thanks a lot for your advice, however I have
> some
> > > problem with the feedback provided by ADI
> > compiler. In
> > > fact for example in CCS there are tools that say
> > you
> > > how much is exploited your pipeline, how are
> > balanced
> > > the acces to the different functional units etc.
> > > I didn-t find nothing like that in ADI, or
> better
> > I
> > > found the pipeline viewer that-s a very
> beautiful
> > > tool, but that cannot be used if you use DMA
> > becuse
> > > the simulator seems not to support this hardware
> > > specific aspect.
> > > Thanks a lot Giovanni
> >
> > the blackfin\\\'s pipeline is not so sophisticated as
> > the SHARC\\\'s,
> > nor as complicated as some TI parts. I would hope
> > that the
> > tool that helps tell you how well the pipeline is
> > full could
> > also tell the compiler how to optimize things
> > better. At present
> > this is a state of the art challenge.
> >
> > I think the VDSP comes with a profiling tool so
> you
> > can see how many clock
> > cycles you spend in any one location. That may
> help
> > point you to places
> > that need further optimization, but it won\\\'t
> > necessarily tell you how full
> > your pipes are.
> >
> > Patience, persistence, truth,
> > Dr. mike > Jaime Andr Aranguren Cardona
> jaime.aranguren@jaim...
> jaime.aranguren@jaim... >
>
> __________________________________
>
>
___________________________________
Nuovo Yahoo! Messenger: E\\\' molto pidivertente: Audibles, Avatar, Webcam, Giochi, Rubrica Scaricalo ora!
http://it.messenger.yahoo.it
now I will read the documentation provided from ADI.
Thanks again for your hint.
Talking about the other question that I posted in fact
you re right, my question should be "how to understand
how good is the assembler code produced by the
compiler", but my english is not so good..
Thanks again
Giovanni --- Jaime Andres Aranguren Cardona
<jaime_aranguren@jaim...> ha scritto:
> Giovanni,
>
> Try to read on PGO (Profile Guided Optimization). As
> I
> undertand it, it is a means to gather information at
> runtime from the execution of the program, which can
> be used to help the compiler to produce more
> efficient
> code. regarding this topic, I\\\'d expect to exist some
> documntation on your original question: "How to
> understand assembler", or better said, "how to
> understand what the compiler did to produce that
> assembly code". Another question, is "how to
> understand how good is the assembler code produced y
> the compiler"
>
> Rgards,
>
> JaaC
>
> --- Mike Rosing <eresrch@eres...> wrote:
> > On Tue, 17 May 2005, Giovanni Parodi wrote:
> >
> > > Thanks a lot for your advice, however I have
> some
> > > problem with the feedback provided by ADI
> > compiler. In
> > > fact for example in CCS there are tools that say
> > you
> > > how much is exploited your pipeline, how are
> > balanced
> > > the acces to the different functional units etc.
> > > I didn-t find nothing like that in ADI, or
> better
> > I
> > > found the pipeline viewer that-s a very
> beautiful
> > > tool, but that cannot be used if you use DMA
> > becuse
> > > the simulator seems not to support this hardware
> > > specific aspect.
> > > Thanks a lot Giovanni
> >
> > the blackfin\\\'s pipeline is not so sophisticated as
> > the SHARC\\\'s,
> > nor as complicated as some TI parts. I would hope
> > that the
> > tool that helps tell you how well the pipeline is
> > full could
> > also tell the compiler how to optimize things
> > better. At present
> > this is a state of the art challenge.
> >
> > I think the VDSP comes with a profiling tool so
> you
> > can see how many clock
> > cycles you spend in any one location. That may
> help
> > point you to places
> > that need further optimization, but it won\\\'t
> > necessarily tell you how full
> > your pipes are.
> >
> > Patience, persistence, truth,
> > Dr. mike > Jaime Andr Aranguren Cardona
> jaime.aranguren@jaim...
> jaime.aranguren@jaim... >
>
> __________________________________
>
>
___________________________________
Nuovo Yahoo! Messenger: E\\\' molto pidivertente: Audibles, Avatar, Webcam, Giochi, Rubrica Scaricalo ora!
http://it.messenger.yahoo.it
Reply by ●May 19, 20052005-05-19
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
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