• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Subscribers 82 subscribers
  • Views 1239 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.

Delay between external trigger and DMA transfer using McBSP

Gabriel Brunheira
Intellectual 440 points

Hi,

I'm using DMA channels to control the dataflow from an external ADC to the shared memory from F28M36, through the McBSP port configured as SPI Master.

After the end of the A/D conversion, the BUSY_OUT signal from the ADC externally triggers DMA-CH1 (XINT1 negative-edge), which starts a "dummy" SPI transfer, in order to receive the most recent sample. Then MREVT flag from McBSP triggers DMA-CH2 to move the sample from DRR registers to the Shared RAM.

The concept was successfully implemented in a F28M36 ControlCard (C28 @ 150 MHz) and the resulting waveforms are showed in the figure below. My question is whether the delay of 440 ns measured between the XINT1 trigger (negative-edge of BUSY_OUT signal) and the start of transmission (first positive-edge of SPI_CLK) is expected or not, and whether it can be reduced. It seems too long to me, since it corresponds to 66 sys_clk's!

Thanks in advance!


Gabriel

  • 0 in reply to Gabriel Brunheira
    Guru 30330 points
    Gabriel,

    Are you still facing issues here? you are right that 66 cycles does seem like a lot. Let's take a look at where the delays are coming from.

    Check out this FAQ on Interrupts in C2000: processors.wiki.ti.com/.../Interrupt_FAQ_for_C2000
    First of all, an external interrupt will take 16 cycles for the Full Context Save/Restore. If you ISR is in wait-stated memory, you will incur additional delays. I.e. if your ISR is located in flash, then you will incur additional delays. 3 per instruction at 150MHz. Depending on the number of instructions inside of your XINT interrupt before initiating the actual transmission, the time may add up.

    There will also be some delay from writing your dummy 'data' to this data being copied from the DXR1 to the transmit shift register, then out to the pin. I do not have the exact timing for this process at the moment, but more than a few cycles seems excessive here.

    At the moment, my best suggestion is to ensure your ISR is mapped to a RAM location to avoid the Flash wait-state delay. You could optimize your code to initiate the dummy write earlier as well.

    If this timing is still too much, or you have more questions, please let me know!

    Regards,
    Mark
  • 0 in reply to Mark Labbato
    Intellectual 440 points
    Hi Mark,

    Thank you very much for your reply!

    I'm a little bit confused for you mentioning Full Context Save/Restore, ISR and instructions at Flash/RAM memory in this context, because the "dummy" data is written by DMA controller externally triggered. I understand that there's limited number of transfers executed by the DMA controller, which implies that once in a while the CPU is interrupted by it, determined by the transfer size, right? But I'm using transfer sizes greater than one burst, and it would occur after the transfer of the dummy data anyway, not before.

    Furthermore, this CPU interrupt from the end of DMA transfers is already executed from RAM memory.

    Do all these enter/exit ISR related overheads apply to the DMA controller as well?

    It seems to me that delays related to the transfer of DXR to the shift register still apply in this case.

    There's one more information I forgot to mentioned: it's a 20 bit transfer, so the DMA controller needs two 16-bit transfers, i.e., burst size is 2. I believe this would also include an overhead, right? Even though, 66 sysclk's still looks too much to me.

    Best Regards!

    Gabriel
  • 0 in reply to Gabriel Brunheira
    Guru 30330 points
    Gabriel,

    What is your LSPCLK setting? SYSCLK/1, /2, /4, /8?

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

    My current LSPCLK setting is SYSCLK/4 and CLKGDV is 1, i.e., it's generating a 18.75 MHz clock for the McBSP as SPI Master.

    What's the point?

    According to the F28M36 specs, I could go up to 25 MHz, but I wanted to keep a larger safety margin due to propagation delays from buffers used in this SPI interface.

    Thanks,

    Gabriel
  • 0 in reply to Gabriel Brunheira
    Guru 30330 points
    Gabriel,

    I have been getting some assistance on this and needed that clock rate for a timing calculation.
    Here is what I have found so far:
    A. Time for XINT Synchronization: ~3 SYSCLK cycles = 20.01ns
    B. Time for DMA to transfer the dummy data to DXR2 then DXR1: 1 cycle to start, 6 for each word = 13 SYSCLK cycles = 86.71ns
    C. Time from DXR1 being copied to a valid MCLKX Signal = 5 CLKX cycles. CLKX = SYSCLK/8 = 5*53.36ns = 266.8ns

    Total time accounted for is 20.01ns + 86.71ns + 266.8ns = 373.52ns.

    I am still tracking down this last 10 SYSCLK cycles.

    You do not have an XINT ISR running, correct? The XINT is wired up to DMA and the DMA interrupt is when the transfer is complete?

    Thanks,
    Mark
  • 0 in reply to Mark Labbato
    Intellectual 440 points
    Wow! What nice numbers you have there, Mark! Although there're still these 10 SYSCLK cycles, your answer is what I was looking for!

    I don't have any ISR associated to XINT or DMA. DMA is running in mode CONTINUOUS.

    Could you give me more explanation about the last (and longest) timing calculation, or just indicate where I can find it in the Technical Reference manual?

    Best Regards,

    Gabriel
  • 0 in reply to Gabriel Brunheira
    Guru 30330 points
    Gabriel,

    I'm glad I was able to help.

    Regarding the timing: the 5 CLKX cycles is how the module was designed. It takes 3 CLKX cycles for the DXR to register and then be copied to the internal Transmit shift register, and then an additional 2 cycles to move the state machine from idle to starting the external CLKX generation

    I will get this information added to the McBSP Chapter.

    Thanks,
    Mark
  • 0 in reply to Mark Labbato
    Guru 30330 points
    Gabriel,

    I got a little more information overnight.
    We found where the extra ~10 SYSCLK cycles is coming from.

    The internal DXR write detection logic may incur an additional CLKX cycle delay if the timings don't align properly. This additional cycle is another 53ns.

    Also the path from the McBSP to the IO pin will take ~2 SYSCLK cycles or ~14ns.

    I think we can sufficiently say that we have traced the entire route of your transmission path :)

    The biggest factor in the timings is the McBSP Clock rate. If you cannot speed this up any more, you look to be stuck with the ~440ns delay.

    Regards,
    Mark
  • 0 in reply to Mark Labbato
    Intellectual 440 points

    Hi Mark,

    I'm here just to further contribute to this topic posting the same image from the original question, but for LSPCLK = 75 MHz. We can see that 440 ns delay was reduced to 328 ns. I didn't make the calculations, but it seems that your estimations would apply correctly in the case too.

    Best Regards,


    Gabriel