• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 98 subscribers
  • Views 530 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.

AM1705 MCASP tx/rx sync problem

Alessandro Barreiros Maurici
Prodigy 50 points
Other Parts Discussed in Thread: AM1705

Hello,

We are using an AM1705 processor in our product, and we heavly depend on serial port

for peripherics communication, but there are some behavior issues with am1705 mcasp.

If we use burst mode to simulate a spi like transfer,  the receive buffer is filled with 0's in the

 first three bytes, the first byte of the transfer appears in the third position of the rx buffer,

and last three bytes of the transfer are lost .Something simular happens with TDM mode,

in the first transfer we get the first 3 channels with 0's, then, real channel 0 starts at slot 3, but

unlike burst mode, in the next transfer we receive the last 3 channels of the last transfer as the first

3 channels of the actual transfer.

This behavior happens with or without using DMA transfer, with and without FIFO enabled. This

problem occours in our linux driver and in a small test program that does not use any OS.

The mcasp is always configured in SYNC mode, using tx clock and tx fs, the two can be provided

 from an external source by the internal clock.

 

 Any suggestions for correcting this problem?

 

Regards,

Alessandro

  • 0
    Prodigy 50 points

    There is a code snippet for a burst transfer that uses internal clock, burst mode, no fifo, dma serviced through peripheral port, in this

    case we always get the first three bytes of the buffer filled with 0's, but the tx is fine. Servicing dma through dma port and/or using fifo

    makes no difference.

    unsigned int PFunc, PDir, RT_fmt, AChan, GBLCTL_reg;

    GBLCTL_reg = 0;

    mcasp_set_ctl_reg( Dev->Regs + DAVINCI_MCASP_GBLCTL_REG, GBLCTL_reg, 0 );

    mcasp_set_reg( Dev->Regs + DAVINCI_MCASP_XMASK_REG, 0xFFFFFFFF );
    mcasp_set_reg( Dev->Regs + DAVINCI_MCASP_XFMT_REG, 0x0001A03A );
    mcasp_set_reg( Dev->Regs + DAVINCI_MCASP_AFSXCTL_REG, ( 1 << 1 ) );

    mcasp_set_reg( Dev->Regs + DAVINCI_MCASP_ACLKXCTL_REG, ( 1 << 5 ) );
    mcasp_set_reg( Dev->Regs + DAVINCI_MCASP_AHCLKXCTL_REG, 0x0000800B );

    mcasp_set_reg( Dev->Regs + DAVINCI_MCASP_XTDM_REG, ( 1 << 0 ) );
    mcasp_set_reg( Dev->Regs + DAVINCI_MCASP_XINTCTL_REG, 0 );
    mcasp_set_reg( Dev->Regs + DAVINCI_MCASP_XCLKCHK_REG, 0 );

    mcasp_set_reg( Dev->Regs + DAVINCI_MCASP_RMASK_REG, 0xFFFFFFFF );
    mcasp_set_reg( Dev->Regs + DAVINCI_MCASP_RFMT_REG, 0x0001C03E );
    mcasp_set_reg( Dev->Regs + DAVINCI_MCASP_AFSRCTL_REG, 0 );
    mcasp_set_reg( Dev->Regs + DAVINCI_MCASP_RTDM_REG, ( 1 << 0 ) );
    mcasp_set_reg( Dev->Regs + DAVINCI_MCASP_RINTCTL_REG, 0 );
    mcasp_set_reg( Dev->Regs + DAVINCI_MCASP_RCLKCHK_REG, 0 );

    mcasp_set_reg( Dev->Regs + ( DAVINCI_MCASP_XRSRCTL_BASE_REG + 0 ), 0x01 );
    mcasp_set_reg( Dev->Regs + ( DAVINCI_MCASP_XRSRCTL_BASE_REG + 4 ), 0x02 );

    PFunc = 0xFE00FFFF;
    PFunc &= ~( 1 << 28 | 1 << 26 | 1 << 1 | 1 << 0 );
    mcasp_set_reg( Dev->Regs + DAVINCI_MCASP_PFUNC_REG, PFunc );
    PDir = ( 1 << 28 ) | ( 1 << 26 ) | ( 1 << 0 );
    mcasp_set_reg( Dev->Regs + DAVINCI_MCASP_PDIR_REG, PDir );

    mcasp_set_reg( Dev->Regs + DAVINCI_MCASP_DITCTL_REG, 0 );
    mcasp_set_reg( Dev->Regs + DAVINCI_MCASP_DLBCTL_REG, 0 );
    mcasp_set_reg( Dev->Regs + DAVINCI_MCASP_AMUTE_REG, 0 );

    GBLCTL_reg |= ( 1 << 9 );
    mcasp_set_ctl_reg( Dev->Regs + DAVINCI_MCASP_GBLCTL_REG, GBLCTL_reg, 0 );
    GBLCTL_reg |= ( 1 << 8 );
    mcasp_set_ctl_reg( Dev->Regs + DAVINCI_MCASP_GBLCTL_REG, GBLCTL_reg, 0 );

    mcasp_set_reg( Dev->Regs + DAVINCI_MCASP_XSTAT_REG, 0x1FF );
    mcasp_set_reg( Dev->Regs + DAVINCI_MCASP_RSTAT_REG, 0x1FF );

    edma_write_slot( Dev->DMA_TX_channel, &Dev->DMA_slot_tx_template );
    edma_write_slot( Dev->DMA_RX_channel, &Dev->DMA_slot_rx_template );

    edma_set_transfer_params( Dev->DMA_RX_channel, 1, TransferSize, 1, 0, ASYNC );
    edma_set_dest( Dev->DMA_RX_channel, ( u32 )( Dev->DmaRxBuffer_addr ), INCR, W8BIT );
    edma_set_transfer_params( Dev->DMA_TX_channel, 1, TransferSize, 1, 0, ASYNC );
    edma_set_src( Dev->DMA_TX_channel, ( u32 )( Dev->DmaTxBuffer_addr ), INCR, W8BIT );

    edma_clear_event( Dev->DMA_RX_channel );
    edma_clear_event( Dev->DMA_TX_channel );
    edma_start( Dev->DMA_RX_channel );
    edma_start( Dev->DMA_TX_channel );

    GBLCTL_reg |= ( 1 << 2 ) | ( 1 << 10 );
    mcasp_set_ctl_reg( Dev->Regs + DAVINCI_MCASP_GBLCTL_REG, GBLCTL_reg, 0 );
    GBLCTL_reg |= ( 1 << 3 ) | ( 1 << 11 );
    mcasp_set_ctl_reg( Dev->Regs + DAVINCI_MCASP_GBLCTL_REG, GBLCTL_reg, 0 );
    GBLCTL_reg |= ( 1 << 4 ) | ( 1 << 12 );
    mcasp_set_ctl_reg( Dev->Regs + DAVINCI_MCASP_GBLCTL_REG, GBLCTL_reg, 0 );

     

  • 0 in reply to Alessandro Barreiros Maurici
    TI__Genius 14545 points

    Alessandro,

      It sounds like the buffers are out of sync with respect to the frame sync. Getting 0's on the first three bytes can possibly occur with a Tx Buffer underrun condition. When this condition occurs, the McASP will output all 0's on each serializer pin until the condition is corrected, however your observation that the last three bytes of subsequently transfered to the first three bytes of the next buffer indicates that the under run condition may only be present on the first frame of the signal.

    Do you see an buffer under run condition at all?

     

     

     

     

     

     

     

  • 0 in reply to dabuan
    Prodigy 50 points

    Drew,

    Sorry for the delayed response, but we saw that the problem only occurs when using the rotation option, in the code i put above, it´s using 8 bits slots with a 24 bits rotation, in this case the first 24bits of the first buffer are zeros, and the next buffer the first 24bits holds the last 24bits of the first buffer and this delay is propagated forever. The same occurs with 16 bits transfer with 16 bits rotation, but following the sequence, the problem occurs only with the first 16bits. We never had a buffer underrun condition in the tests, and this behavior is always present when using rotation.

    We solved the issue disabling hardware rotation and modifying the software to deal with that when required.

     

  • 0 in reply to Alessandro Barreiros Maurici
    TI__Genius 14545 points

    Thanks for the follow up.

    Glad to see you were able to solve the issue.