• State TI Thinks Resolved
  • Locked Locked
  • Replies 1 reply
  • Answers 1 answer
  • Subscribers 99 subscribers
  • Views 492 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.

Original question:

RTOS/TMS320C6657: CCS example project for NDK 3.40.01.01

RTOS/TMS320C6657: McBSP Loopback

Steven Sherbert
Intellectual 580 points

Part Number: TMS320C6657

Tool/software: TI-RTOS

Hi - I installed the processor_sdk_rtos_c665x_5_03_00_07 and in the process of porting our McBSP driver.  I am running into an issue where data is not being received in the expected order.   I have the McBSP configured in loopback mode and the TCC DMA configured to receive the appropriate events.   Verified the TX/RX events are occuring and that the Param blocks are settup and executing correctly.   The DMA is configure to transfer data using the McBSP FIFO.  Everything seems to be plumbed correctly but there is an issue with how the data is being transfered. Using fixed data in the transfer buffer, received data is not coming in on the same slot or even sequentially.  Looks like data is missing or randomly being transfered between the TCC DMA and McBSP FIFO.   It is diffucult to debug any further since there are no errors reported.

Questions:

Q1. The c6657 does not have access to pin mux and gpio blocks like other processors.  The blocks in the c6657 are powerd on by default and the need to configure any gpio or pin mux is not obvious.   The only detail that I am not confident with is if there requires initialization of these gpio and pin mux registers to run the McBSP in Loopback mode?

Q2.  Is there any method to isolate DMA data being sent to the McBSP TX FIFO and what DMA data is being read out of the McBSP RX FIFO?

Q3.  I have set up manual data transfers using the McBSP and verifyied data being sent is received.   One concern that I have is that if I don't put a delay between wrting TX data and reading RX data then I don't reliably get expected data.   I was expecting testing for RRDY and XEMPTY would be adequate.   Was wondering if this is expected and if not may be related to the DMA issues I am seeing?

Thanks,

-Steve

  • 0
    TI__Guru** 116830 points

    Steven Sherbert said:
    Q1. The c6657 does not have access to pin mux and gpio blocks like other processors.  The blocks in the c6657 are powerd on by default and the need to configure any gpio or pin mux is not obvious.   The only detail that I am not confident with is if there requires initialization of these gpio and pin mux registers to run the McBSP in Loopback mode?

    Please check Tom`s response on the GPIO mux functionality on this device. 

    https://e2e.ti.com/support/processors/f/791/t/635146

    MCBSP Loopback mode functionality is tested on the C6657 EVM using MCBSP LLD driver. Have you checked out the sample code execution on the C6657 EVM before trying this out on your custom designed HW.

    Steven Sherbert said:
    Q2.  Is there any method to isolate DMA data being sent to the McBSP TX FIFO and what DMA data is being read out of the McBSP RX FIFO?

    From a MCBSP driver perspective, the user only passes the EDMA3 handle to the mcbspCreateChan API call. The isolation of data is done at application level by maintaining two separate rxbuf and txbuf buffers that are filled in by the transmit and receive side. If you look at the file at the location in PDK 

    pdk_c665x_2_0_13\packages\ti\drv\mcbsp\example\c6657\MCBSPDigLpbk\mcbspMasterDigLpbk\mcbspMasterDigLpbk.c 

    You will see how the RX and TX side data is handled using ping pong mechanism when used with mcbspSubmitChan API for transmitting and receiving data buffers from MCBSP FIFO. 

    Steven Sherbert said:
    Q3.  I have set up manual data transfers using the McBSP and verifyied data being sent is received.   One concern that I have is that if I don't put a delay between wrting TX data and reading RX data then I don't reliably get expected data.   I was expecting testing for RRDY and XEMPTY would be adequate.   Was wondering if this is expected and if not may be related to the DMA issues I am seeing?

    I believe that this is expected. We implement this using edmaTxDone and edmaRxDone global flags in the loopback sample code. The flag is set and reset using MCBSP callback function. Check the function mcbspAppCallback and look for the comment that describes implementation of this wait delay. Line 602 in the file referenced above contains this wait implementation. 

    Hope this helps.

    Regards,

    Rahul