• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 98 subscribers
  • Views 671 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

C6747 MCASP delay 2 bits with EDMA3 problem

Lian
Intellectual 370 points
Now I use MCASP to sent data out with EDMA3. For the MCASP, the ACLKX and AFSX are both internal. And I set the XDATDLY=2 in AFMT, which means the first transmit data bit, AXR[n], occurs two ACLKX cycles after the transmit frame sync. The MCASP works in Burst transfer mode. So when I take the MCASP out of reset, the EDMA will move the transfer data to the XBUF in turn. When there is no delay( XDATDLY=0) , the sending data is right. However, when XDATDLY=2, the sending data is really delaying 2bits, but between 2 AFSX, there is always just 32 numbers of CLKX, so the last 2 bits of sending data is postponed to beginning of next FSX. How to solve this problem? Thanks a lot!
  • 0
    TI__Guru* 84110 points

    Lian,

    What you describe is exactly the behavior shown in the McASP User's Guide in section 2.4.2.1 in Figure 23 on page 38. This is not a problem, but rather this is the solution to the problem of getting full bandwidth from the McASP data line(s) with any of the delay values.

    The AFSX is not a data enable signal but instead it is a data start signal. Some receivers do not require a delay and some do require a delay. In the case of XDATDLY=2, the receiver will start capturing data 2 cycles after the AFSX is received and will continue capturing data for a total of 32 bit clocks, for a 32-bit data word. The receiver must then be capable of noting the next AFSX signal while still capturing the previous slot of data, and then continuing capture of a new 32-bit word 2 cycles later.

    If it is easier to use XDATDLY=0 or 1, then those options are also available.

    If this does not resolve your question, please provide additional information about why this is a problem in your case.

    Regards,
    RandyP

     

    If this answers your question, please click the  Verify Answer  button below. If not, please reply back with more information.

  • 0 in reply to RandyP
    Intellectual 370 points

    Thanks for your reply! Your post said that the phenomenon that I described is is just what should be. Because I use DSP to connect with FPGA through MCASP. After the FPGA receives the 32bits, I hope there will be 2 clock cycle for FPGA to handle the data. so is there a method to make that there is 34 numbers of CLOCK between 2 FSX.

    Thanks a lot!

  • 0 in reply to Lian
    TI__Guru* 84110 points

    Lian said:
    is there a method to make that there is 34 numbers of CLOCK between 2 FSX.

    There is nothing that I know of. You may wish to carefully review the McASP User's Guide for the various modes of operation to see if there is any method you could adapt, but I cannot think of it.

    Regards,
    RandyP

  • 0 in reply to RandyP
    Intellectual 370 points
    Thanks for your reply! I think you are right! So now I let the FPGA deal with the receiving data after it has completed the receive. Thanks a lot!