• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 82 subscribers
  • Views 542 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.

McBSP Transmit Delay at the beginning of a packet

Ayaka Ohira
Intellectual 440 points
Other Parts Discussed in Thread: CONTROLSUITE

Hi there,

I have TMX F28069 device and using McBSP to output a custom serial signal.

The signal is a plain 50k baudrate, transmits for 5120bits (102.4ms)

To send the 5120 bits, I have setup DMA to transfer 16 blocks of 20bits word at a time.

At the end of the transfer, DMA is halted and McBSP transmit pin is remapped to normal GPIO.

After 5ms, McBSP transmit is enabled by reassigning the transmit pin to McBSP and re-starting the DMA.

What we are seeing is that at the beginning of every transfer cycle, after I re-initialise the McBSP I see around 40us of delay before the data is output to the physical pin. 

My question is, could someone be able to explain why I'm seeing 40us of delay at the beginning of the transmit cycle?

Is it related to the comment in the data sheet :

" Note: Even if multiple words are consecutively transferred, the CLKX signal is always stopped and the FSX signal returns to the inactive state after a packet transfer. When consecutive packet transfers are performed, this leads to a minimum idle time of two bit-periods between each packet transfer."

If it is related to this comment then I would have expected to see 2 bit-period delay after every 20bits have been transferred.

Please let me know if I need to provide more information.

Thanks,

Ayaka

P.S. Using IDE: ccs v6, Not using a code from controlSUITE. I have written the code

  • 0
    Guru 30330 points
    Ayaka,

    I am curious why you are reinitializing the module and reallocating the GPIO in between transfers? Why not just do a One-shot transfer with the DMA, and trigger it to start and your required interval?

    The note that you quote applies to SPI mode only. Are you operating in SPI mode?

    Regardless of the above reasoning, Can you share some screenshots of the behavior? If you could add some GPIO toggles or notation on a scope capture of when the DMA is started and when the first word begins transmitting.

    Does the 40us delay occur from the time that the DMA is enabled to the time the first word appears?

    The timings don't look too far out of the realm of possibility. 2 bit times of a 50KHz clock is 40us. I need to dig around to see if I can find the timings from the first word to it being present on the line.

    -Mark
  • 0 in reply to Mark Labbato
    Intellectual 440 points

    Hi Mark,

    Thank you for your response. There is a reason behind re-initialising the module. GPIO does not have to be remapped in the meantime I suppose. I didn't use the one-shot transfer; every 16 * 20bits, I am checking data that is going to be sent through in a way..

    No, I'm not operating in SPI mode.

    I am sorry but I cannot provide screenshot at the moment. But basically 40us is as you said, from the moment I initialise the Mcbsp, GPIO and hit Run on DMA till the moment I see the Mcbsp Tx line go high given that the first 20bits in the buffer is 0xFFFFF.

    The other thing I found it interesting is that in any of the diagram that explains the mcbsp transmit, there always seem to be a 2 cycles before the frame sync pulse? Example attached:

    Also, I have tried changing the clock to 30kHz and see if this delay time would change and it did. I was getting 69us. So it is definitely related to the transmit clock time.

    Would it help if I post the Mcbsp setup code?

    Thanks,

    Ayaka