• State TI Thinks Resolved
  • Locked Locked
  • Replies 2 replies
  • Answers 2 answers
  • Subscribers 100 subscribers
  • Views 306 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.

TMS320C6657: C6657 MCBSP XDATAY issue.

Denny%20Yang99373
Expert 3805 points

Part Number: TMS320C6657

Hi all,

I have set XDATDLY and RDATDLY to 1. And send 16bit data.

It should delay one clock and used 17 clock for a frame transmit.

But I found the first frame used 17 clocks but others used 16 clocks. In my understand all frame should make 17 clocks. please help to double confirm, thanks!

As attached picture, I send 0xaaaa.

BR,
Denny

  • 0
    TI__Guru** 116830 points

    Denny,

    When the XDATDLY and RDATDLY are set to 1. The data starts showing 1 bit clock cycle after the frame sync and finish 1 cycle after the next frame sync so for 0xaaaa data, the last 0 bit  in sequence (1010 1010 1010 1010 b) appears after the next frame sync. At this point the next data would be starting 1 bit after the next frame sync so the 17 clocks will only appear the first time the data starts to shift out since all subsequent data will automatically be delayed by 1 bit clock as the end of previous data will happen 1 bit clock after the next frame sync. I don`t think seeing 17 bit clocks between every frame sync is the expected behavior by adding this delay.

    Regards,

    Rahul

  • 0 in reply to Rahul Prabhu
    TI__Guru*** 125430 points

    Think of it as "offset" rather than delay.  XDATDLY/RDATDLY don't change the number of bits in a frame, they only change the offset between clock and data.