|
Warning Long e-mail
ahead!!
In Short: Edma stalls
seem to arise when using Edma to service two Mcbsps at the same
time.
The Whole Story:
We are using a TMS320C6711 Processor with both
Mcbsp's configured as UARTS. That is the Framing line and the Data
line are tied together on the receive end of the MCBsp and Transceivers are used
to convert to the correct signal levels. We are assuming 8N1 for
Serial communciations giving us ten serial bits per data byte. The
mcbsps are configured assuming 32 bit elements where each element is the pulse
for the RS232 bit. We are using the Internal Clock as the clock source
which gives us Baud rates of 9600 BPS and up. We have, ofcourse,
configured the mcbsp to ignore framing errors as the Receive data and
receive framing lines are tied together. This differs from the mcbsp
settings specified in the TI document. We are using Code Composers
1.2.
Up to this point we have been using the mcbsp
receive interrupts to catch the bits (which then are subsequently converted to
their byte representation) and direct writes to the Mcbsp for
transmission. Due to the need to have precise timing on the writes and the
need to catch the bits on the receive this configuration does not make
simulatanoues mult-channel communication possible.
Now we have just completed an EDMA version such
that the bits are EDMA'd using REVT on the receive end and XEVT on the
Transmit End. The transmission is kick started by writing to the
appropriate Set Event Register. There are separate buffers for each mcbsp
and the buffers are on-chip with the remaining 3/4 of on-chip configured as
cache. There are two linked receive buffers (each holding 10 elements or 1
serial byte) for each mcbsp and there is 1 transmit Buffer for each mcbsp.
Each transmit buffer is linked to a NULL parameter table. I have assigned
different TCC's for each receive buffer to distinguish between received
bytes.
Receptions are translated into their Byte
values in the EDMA ISR (and then placed on a queue). Byte transmission is
driven by the completion of the prior transmission up to the entire data packet
being sent.
This scheme works great as long as Serial
Communication is occurring only on One Mcbsp at a time. Shortly after
attempting to communicate on both simultaneously, EDMA transfers appear to
stall. (NOTE: I have ensured that each port uses independent data
structures, etc).
I have managed to alleviate the problem for
stalls on transmission by ping ponging between ports between the
transmission of bytes from the MCBSP. That is if two blocks of data
need to be sent out the two ports a serial byte is sent out one port than
the serial byte is sent out the other and so on. Once I did this I no
longer received stall outs on the Transmission end. Unfortunately, since I
do not have control of the data sent to the mcbsp fro the outside I cannot
implement this work around on the receive end. Further I cannot be sure
that the stall on the receive side is not also due to a transmission from the
other channel.
So my questions are these:
1) Any Ideas on why I am having problems
with EVT driven EDMA when serial communication occurs on both MCBSP's
simultaneously?
2) What can be done to solve the problem so
that I can ensure that EMDA transfers from both MCBSP do not
interfere?
-Brad
---------------------
Brad Cadle: b...@bioscrypt.com |
|
|
Mcbsp As Uart with EDMA Servicing issue
Started by ●October 10, 2001
Reply by ●October 11, 20012001-10-11
|
We need to be able to simultaneously support up to 115200 bps on the 2 mcbsp's, Wiegand D0 and D1 interrupts, Wiegand LED, Two General purpose Input lines, ans in some configurations capturing image data on another interrupt, all without ever losing any information. Now perhaps you are right in that some portion of the code is doing more that we need to in the ISR.. We do have 860 clock ticks before the bit changes at 115200 (ofcourse we need to capture a majority of the bit to have it correctly decoded this gives us say 430 ticks). Certainly our current non-emda design is not able to handle all at the same time. It does work great however it we are only speaking to the unit on the single input. Perhaps the cache misses contribute to the problem as well. In any case, with EDMA servicing the mcbsps we would have more efficient implementation allowing for less interruption of the processor while it is doing its background tasks. -Brad ----- Original Message ----- From: "Jeff Brower" <> To: "Brad Cadle" <> Cc: <> Sent: Thursday, October 11, 2001 6:20 AM Subject: Re: [c6x] Mcbsp As Uart with EDMA Servicing issue > Brad- > > Curious, but what is the RS-232 bit-rate? If it's the normal slow thing like > 28.8 or 56k, why would you need EDMA to "catch bits"? Even at 128 kbaud or some > amazing RS-232 rate it's still not a big deal to rely on the ISR on a C6711; in > this case the ISR can be really simple -- store the bit. Are you making life > too hard ;-) > > Jeff Brower > DSP/telecom engineer > Signalogic > > On Wed, 10 Oct 2001, "Brad Cadle" <> wrote: > >Warning Long e-mail ahead!! > > > >In Short: Edma stalls seem to arise when using Edma to service two Mcbsps at > the same time. > > > >The Whole Story: > > > >We are using a TMS320C6711 Processor with both Mcbsp's configured as UARTS. > That is the Framing line and the Data line are tied together on the receive end > of the MCBsp and Transceivers are used to convert to the correct signal levels. > We are assuming 8N1 for Serial communciations giving us ten serial bits per > data byte. The mcbsps are configured assuming 32 bit elements where each > element is the pulse for the RS232 bit. We are using the Internal Clock as the > clock source which gives us Baud rates of 9600 BPS and up. We have, ofcourse, > configured the mcbsp to ignore framing errors as the Receive data and receive > framing lines are tied together. This differs from the mcbsp settings specified > in the TI document. We are using Code Composers 1.2. > > > >Up to this point we have been using the mcbsp receive interrupts to catch the > bits (which then are subsequently converted to their byte representation) and > direct writes to the Mcbsp for transmission. Due to the need to have precise > timing on the writes and the need to catch the bits on the receive this > configuration does not make simulatanoues mult-channel communication possible. > > > > > >Now we have just completed an EDMA version such that the bits are EDMA'd using > REVT on the receive end and XEVT on the Transmit End. The transmission is kick > started by writing to the appropriate Set Event Register. There are separate > buffers for each mcbsp and the buffers are on-chip with the remaining 3/4 of > on-chip configured as cache. There are two linked receive buffers (each holding > 10 elements or 1 serial byte) for each mcbsp and there is 1 transmit Buffer for > each mcbsp. Each transmit buffer is linked to a NULL parameter table. I have > assigned different TCC's for each receive buffer to distinguish between received > bytes. > > > >Receptions are translated into their Byte values in the EDMA ISR (and then > placed on a queue). Byte transmission is driven by the completion of the prior > transmission up to the entire data packet being sent. > > > >This scheme works great as long as Serial Communication is occurring only on > One Mcbsp at a time. Shortly after attempting to communicate on both > simultaneously, EDMA transfers appear to stall. (NOTE: I have ensured that each > port uses independent data structures, etc). > > > >I have managed to alleviate the problem for stalls on transmission by ping > ponging between ports between the transmission of bytes from the MCBSP. That is > if two blocks of data need to be sent out the two ports a serial byte is sent > out one port than the serial byte is sent out the other and so on. Once I did > this I no longer received stall outs on the Transmission end. Unfortunately, > since I do not have control of the data sent to the mcbsp fro the outside I > cannot implement this work around on the receive end. Further I cannot be sure > that the stall on the receive side is not also due to a transmission from the > other channel. > > > >So my questions are these: > >1) Any Ideas on why I am having problems with EVT driven EDMA when serial > communication occurs on both MCBSP's simultaneously? > > > >2) What can be done to solve the problem so that I can ensure that EMDA > transfers from both MCBSP do not interfere? > > > > > >-Brad |
Reply by ●October 11, 20012001-10-11
|
Brad- Curious, but what is the RS-232 bit-rate? If it's the normal slow thing like 28.8 or 56k, why would you need EDMA to "catch bits"? Even at 128 kbaud or some amazing RS-232 rate it's still not a big deal to rely on the ISR on a C6711; in this case the ISR can be really simple -- store the bit. Are you making life too hard ;-) Jeff Brower DSP/telecom engineer Signalogic On Wed, 10 Oct 2001, "Brad Cadle" <> wrote: >Warning Long e-mail ahead!! > >In Short: Edma stalls seem to arise when using Edma to service two Mcbsps at the same time. > >The Whole Story: > >We are using a TMS320C6711 Processor with both Mcbsp's configured as UARTS. That is the Framing line and the Data line are tied together on the receive end of the MCBsp and Transceivers are used to convert to the correct signal levels. We are assuming 8N1 for Serial communciations giving us ten serial bits per data byte. The mcbsps are configured assuming 32 bit elements where each element is the pulse for the RS232 bit. We are using the Internal Clock as the clock source which gives us Baud rates of 9600 BPS and up. We have, ofcourse, configured the mcbsp to ignore framing errors as the Receive data and receive framing lines are tied together. This differs from the mcbsp settings specified in the TI document. We are using Code Composers 1.2. > >Up to this point we have been using the mcbsp receive interrupts to catch the bits (which then are subsequently converted to their byte representation) and direct writes to the Mcbsp for transmission. Due to the need to have precise timing on the writes and the need to catch the bits on the receive this configuration does not make simulatanoues mult-channel communication possible. > > >Now we have just completed an EDMA version such that the bits are EDMA'd using REVT on the receive end and XEVT on the Transmit End. The transmission is kick started by writing to the appropriate Set Event Register. There are separate buffers for each mcbsp and the buffers are on-chip with the remaining 3/4 of on-chip configured as cache. There are two linked receive buffers (each holding 10 elements or 1 serial byte) for each mcbsp and there is 1 transmit Buffer for each mcbsp. Each transmit buffer is linked to a NULL parameter table. I have assigned different TCC's for each receive buffer to distinguish between received bytes. > >Receptions are translated into their Byte values in the EDMA ISR (and then placed on a queue). Byte transmission is driven by the completion of the prior transmission up to the entire data packet being sent. > >This scheme works great as long as Serial Communication is occurring only on One Mcbsp at a time. Shortly after attempting to communicate on both simultaneously, EDMA transfers appear to stall. (NOTE: I have ensured that each port uses independent data structures, etc). > >I have managed to alleviate the problem for stalls on transmission by ping ponging between ports between the transmission of bytes from the MCBSP. That is if two blocks of data need to be sent out the two ports a serial byte is sent out one port than the serial byte is sent out the other and so on. Once I did this I no longer received stall outs on the Transmission end. Unfortunately, since I do not have control of the data sent to the mcbsp fro the outside I cannot implement this work around on the receive end. Further I cannot be sure that the stall on the receive side is not also due to a transmission from the other channel. > >So my questions are these: >1) Any Ideas on why I am having problems with EVT driven EDMA when serial communication occurs on both MCBSP's simultaneously? > >2) What can be done to solve the problem so that I can ensure that EMDA transfers from both MCBSP do not interfere? > > >-Brad |
