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 |