Because of the Thanksgiving holiday in the U.S., TI E2E™ design support forum responses may be delayed from November 25 through December 2. Thank you for your patience.

  • State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 100 subscribers
  • Views 365 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

DM640 MCBSP based EDMA byte wide data transfer problem

mahdi monhi
Prodigy 40 points
Other Parts Discussed in Thread: TMS320DM640

Dear Experts

In a Computer telephony project based on TMS320DM640 we use both MCBSP1 and MCBSP2 to transmit and receive byte wide data to and from ST-BUS.

ST-BUS is a Multichannel TDM bus which transmits and receives serial data. each frame of this bus consists of 32 channel and frames are separated by using frame sync signal.

MCBSP1 uses both transmit and receive paths but MCBSP2 just uses transmit path of data.

Both MCBSPs are configured to use EDMA to transmit and receive data. Thus ping pong structure is used.

Lengh of each EDMA buffer is 7680 bytes (240 bytes for each of 32 channel ) and all buffers are configured to be in Internal memory.

DSP/BIOS is used in this project and all EDMA interrupts are assigned to INT_8 which calls _EDMA_intDispatcher (Dispatcher is active).

In DSP/BIOS, INT_8 is configured in a way that it only mask itself from occurring again (interrupt mask = self)

there is no problem with TCC and receiving interrupts and all 3 channels work properly.

But problem :

I send some signaling data in 17th time slot of MCBSP2 based of EDMA. but rarely I find that 2 or 3 bytes of ping buffer are transmitted between pong buffer and vice versa.

I fill ping buffer with 0xCD and pong buffer with 0xED and activate program but some time in my monitor program which is a PC based application, I see ping buffer like this:

CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD ED ED CD CD CD CD

2 or 3 number of ED bytes from pong data visited in ping data and vice versa , EDs occur at random places and I have no idea how it could happen.

Program is big and I have to use external SDRAM and caching mechanism. but as mentioned earlier, all EDMA buffers are inside internal memory.

I use CCS 3.3 for this project.

Looking to hearing from you

Mahdi

  • 0
    Prodigy 40 points

    Dear Experts

    I found the problem, It was because of CPLD that I put in front MCBSP2 ST-BUS to activate its 17 time-slot but it has some problems.

    But now I face another problem.

    In the architecture described in first mail, I send EDMA based data of 240 bytes per channel. to see if it works ok or not, I send counter data, e.g 240 bytes of 00 then 240 bytes of 01 and ...  on 17th time-slot of  MCBSP2.

    I could  capture data and save it into a file to see if every thing is ok or not.

    But some times I see a gap between 2 consecutive bunch of numbers like this:

    240 bytes of  0x11

    240 bytes of 0x12

    176 bytes of 0x13

    240 bytes of 0x20

    240 bytes of 0x21

    As mentioned, first instead of getting 240 bytes of next number, I only get 176 bytes, then a big gap appears and then every thing is ok again.(gap fro 0x13 to 0x20 in above example).

    It seems that some MCBSP or EDMA stall occurs.

    But I have no Idea how?

    Both MCBSPs are slave ( CLK and frame sync are input to these modules) and I think some synchronization problem is in front

    again looking to hearing from you

    Regards

    Mahdi

  • 0 in reply to mahdi monhi
    Prodigy 40 points

    Dear Experts

    It seems that EDMA interrupt after sending one block of data occurs several times (without clearing the interrupt bit.) until the next real interrupt. 

    I use EDMA_IntDispatcher and set interrupt mask to "all". it results in lower number of problems. but it exists yet.

    By surfing the web I find EDMA_IntDispatcher clears the interrupt itself and no need to call EDMA_intClear(tcc) function.

    But I have no idea how it might occur again.