McBSP Interrupt configuration for TMS320c6414T ,extarnal Frame sync for receiving and transmitting

Can you explain in more detail what data is coming into the McBSP and what you're trying to accomplish?  Why don't you want to use the EDMA?

So do you have 32 elements per frame sync and you are intentionally discarding the first 31 and keeping only the 32nd?  I suppose it would work with your current scenario.  There's probably a cleaner way to handle it with EDMA depending on what you're trying to do.

Hi Brad...

 Thanks for reply and suggestion....

 In this audio data is coming on McBSP and proecessed for Echo cancellation and then ADPCM encoded and decoded for transmitting towards DECt phone.

We had earlier used EDMA , but we are getting crackliong noise at specific time slot 112.470 usec to 112.510 usec in the frame span of 125 usec at every frame. so for the debugging and using other option ,we had swithced to use CPU  & McBSP configured  directly by removing EDMA interface.

In the frame 125 usec ,we are receiving 32 channels (3.90625 usec each channel time slot) ,we want to receive 32 channels all as well process and transmit toward DECT side ,as well receive all 32 channenls from DECT and process and transmit towards opposite BAck Plane side. So there is no question of discarding of any channel.

But no my query is can we implement for McBSP interrupt to CPU ,using  10h forRINTM /XINTM in the  SPCR register for 32 channels receive and transmit at a time instead of every 1 byte interrupt.

Thanks in advance .

Hi Bradd....

       Adding to above things I am exaplaining the EDMA  problem in detail as follows....

 1) We are using McBSP0 ,MCBSP1 for receive and transmit data in TDM mode.

2) Interrupt EDMA is configured to CPU at INT8 level.

3) Other EDMA events are configured as

a) isrMcBSP0Transmit => Channel 12 Event

b) isrMcBSP0Receive => Channel 13 Event

c) isrMcBSP1Transmit => Channel 14 Event

d) isrMcBSP1Receive =>  Channel 15 Event

4) We are using two frame sync for using this operation , one is using for McBSP0 & other is using for MCBSP1 . When first sync for MCBSP 0 comes , audio data receiving at McBSP0 Receive in the span of 125 usec of 32 channels , which then we are giving input to ECHO cancellation algorithm . 

5) After this sync within 125 usec , second sync which we are configuring for MCBSP1 ,  when this comes we are receiving data from DECT phone through  McBSP 1 receive for 32 channels.This data we are ADPCM decoding and gives to ECHO cancellation algorithm.

6)  The transmitter for both MCBSP are starts transmitting  data through EDMA , at the same time on respective syncs.

7) For every event we are setting bit in CIPRL register through TCC,TCINT (Options Register) . so when any sync comes  EDMA interrupt gets executed and cheks for the event associated ISR which getting executed normally.

7) Now the problem is observing when the difference between these 2 sync is 112.470 usec ,means EDMA interrupt comes and checks the  CIPRL bits but not able to handle the events properly at this specific time and we can listen the crackling noise at both sides .

Please suggest some working solution for this problem.

dspguy_78 said:

But no my query is can we implement for McBSP interrupt to CPU ,using  10h forRINTM /XINTM in the  SPCR register for 32 channels receive and transmit at a time instead of every 1 byte interrupt.

No, when using that mode you only get one interrupt per frame sync, but you will have dropped all samples except the last one.  There is not much internal buffering in the McBSP.  You must service the McBSP after each element is received, where an element can be up to 32 bits.

dspguy_78 said:

We had earlier used EDMA , but we are getting crackliong noise at specific time slot 112.470 usec to 112.510 usec in the frame span of 125 usec at every frame. so for the debugging and using other option ,we had swithced to use CPU  & McBSP configured  directly by removing EDMA interface.

 

Where are your audio buffers being stored?  Internal memory or SDRAM?  Make sure you try it out using internal memory as there are a couple places that could trip you up using external memory.  There could be latency due to competition for the SDRAM interface (e.g. a cache operation would take precedence) and there are also potential cache coherence issues since cache coherence is not maintained by the hardware when sharing external memory between the EDMA and CPU.

Hi Bradd...

  Thanks for suggestions...

 We are using internal memory for storing audio buffers. We are not using SDRAM or external memory at all . Still the problem of crackling noise we are observing.

Hi Bradd..

  Do  you have any other suggestion for these both problem ?

a) EDMA event execution

b) MCBSP interrupt to CPU without using EDMA  as per my explaination in earlier replies.

Thanks in advance.

I may have missed something coming into this conversation, but are you using ping-pong buffering? My guess is that you are not processing the data fast enough to have the input buffer finished and clear before the next sample comes in.

If you have an input buffer of 32 samples then the CPU will begin processing after the EDMA copies the 32nd sample. If the CPU has not completed this processing and moved the contents of your input buffer to the output buffer before the 33rd sample arrives (the first of a new input buffer) you start to get sample loss.

Additionally, if your CPU is taking too long to process the data and the output is starved of data this could have something to do with the crackling you are hearing. Try tweaking with the buffer sizes and/or switch to a ping-pong scheme.

So do you still get the crackling even when servicing with the CPU?  That would tell you whether the problem is with your McBSP configuration or your EDMA configuration.

Hi Tim,

  Thanks for reply and good suggestions.

  We already using PING PONG buffer(2 buffers ) at each end .Means 2 buffers at

a) McBSP0 Receive

b)  McBSP0 Tranmit

c) McBSP1  Receive 

d)  McBSP1 Tranmit

 earlier we are guessing the as you suggested  underrun / overrun buffer problem. Thats why again we trired to increase the extra buffers with 8 buffers at each end . Still we observed the same problem  at the same time slot.

We are using the TMS320c6414T , running on 269.568 MHz .  ( 44.928 Mhz crystal freq  x  6  setting with PLL)

The thing is like only we are getting problem at 2 places , in the frame of 125 usec for 0.40 usec each.  When the both sync diference is  from 112.470 to 112.510  &  other noise at 121.100 to 121.500 usec .

PS: Both sync are moving ,they can not be fixed .

Thanks ,

Ratnakar

Hi Brad..

     If some configuration wrong with McBSP or EDMA then the noise problem comes continuously , but we are observing the problem only at 2 places in the frame span of 125 usec as per my earlier post.

Note that we are using 2 syncs which are externally generated and both are miving very slightly . I mean to say both sync difference varies 1usec in 2 days ... So when both are locked for exact time slot where we are observing crackliong noise ,it will get throughout 2-3 days on all calls.