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

TMS320C6713B DMA transfer issues w/external device

Andrea Ramos
Intellectual 975 points
Other Parts Discussed in Thread: TMS320C6713B

Hello,

Can you please help with the following question:

TMS320C6713B

RTDX is turned off.  All other peripherals are polled.

External RAM is SRAM

I’m having an issue with intermittent DMA transfers from an external device. 

This code is an excerpt from the HWI routine for DMA transfer complete.

I have an I/O bit that is set around reconfiguring (ping/pong) the dma channels.

Something is holding off the transfer interrupt for between 5uS and as much as 30uS, and I’ve been unable to determine what might be doing this.

The channel is configured for HWI_INT10. 

What could be deferring this interrupt?   I think I have  RTDX turned off, although it didn’t seem to make any difference.  Any suggestions?


FPGA_DMA_DISABLE();             // Disable transfers

SET_FPGA_OUT(GENIO_0_BM);       // Turn on I/O         

  // Re-arm both DMA channels

  // Change DMA to other DMA buffers

  EDMA_config(hEdmaIRDMA, IR_DMAConfig[curDMABuff]);

  EDMA_config(hEdmaUVDMA, UV_DMAConfig[curDMABuff]);

  // Re-enable both channels

  EDMA_enableChannel(hEdmaIRDMA);  

  EDMA_enableChannel(hEdmaUVDMA);  

CLR_FPGA_OUT(GENIO_0_BM); 

FPGA_DMA_ENABLE();

  • 0
    TI__Guru* 84110 points

    There may be some more information needed. Are you saying that the time between SET_FPGA_OUT(GENIO_0_BM); and CLR_FPGA_OUT(GENIO_0_BM); varies from 5uS to 30uS?

    What do you mean by "an I/O bit"? Where is this bit, a GPIO on the DSP or a pin on the FPGA?

    How much time does it take if you comment out the four EDMA_* calls? How much if you commend out just the pair of IR calls or the pair of UV calls?

    But if this code is inside the HWI, then how does this relate to what is happening to delay the interrupt that leads to this HWI running?

    Other things going on in the system can delay EDMA transfers and can delay interrupts. If interrupts are masked for too long in a tight loop or inside a function that requires disabling of interrupts, then an interrupt could be disabled.

    It will be helpful for you to get some signal relationships between the data transfers and the occurrence of the interrupt and the execution of the HWI routine.

    Sorry I do not have any answers yet.

    Regards,
    RandyP

  • 0 in reply to RandyP
    Prodigy 10 points

    Thanks Randy,

      The IO is GPIO, and you're right in that the code listed isn't the lions share of my issue.

    Initially, I thought that the variance in the period bookmarked by the I/O was causing my problem.  I've since found that if I disable interrupts for this duration, this timing is constant.

     The real source of my problem is the apparent (and demonstrable) delay between the DMA transfer completion and the DMA complete interrupt.  I've seen as much as 100uS, and there is evidence that there are occasions when it runs longer than this.

      Currently, this DMAComplete is the only ISR that is part of the application.    There are no other interrupts, or periods of interrupts disabled that are part of the application that I've coded.  I am making extensive use of BIOS, with threading and semaphores, timers, etc.  I can see that there are other higher priority interrupts happening, as evidenced by the wrapping of interrupt disable around the transfer complete interrupt stabilizing that timing.

      I should tell you that I actually have two DMA channels configured and am transfering two sets of data.  The second DMA channel has no transfer complete interrupt assigned, both buffers are relieved and both DMA channels re-armed for transfer in this one handler.  This should be OK as this the second channel transfer should be completed long before this one.  The data seems to validate this assumption.

      I can't use chaining to fix this issue (assuming it would) because I have to send a signal to re-arm the capture mechanism in the FPGA.  It's the re-arming that isn't happeing within the available window reliably.

      There must be something that could hold-off this interrupt for an extended variable period.  As I said, I'm not disabling interrupts anywhere else, but I'm not sure about what BIOS, RTDX, Trace, EMIF, or other mechanisms might be doing.

      I'm fairly sure that  I finally have RTDX turned off, and I see no evicence that it has any effect.

      I'm at a loss as to how to determine where this is coming from, can it be mitigated, or is a different paradigm the only solution.

    Please ask further questions,  especially the stupid ones.  I do have the on/off switch in the on position.

    thanks for any direction you might provide.

    -EdA-