• State TI Thinks Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 4 answers
  • Subscribers 102 subscribers
  • Views 1522 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.

AM335x DMTimer and DMA requests

Patrick Trantham
Prodigy 60 points


I have set up a EDMA channel and a transfer to trigger on events from DMTimer 4 and have checked that the parameters are correct by triggering the tranfer requests manually via the ESRH register. Then, I set the bit in the EERH register via the EESRH register to enable channel 48 (timer 4, TINT4) events and enabled the timer. The result is that only one dma resquest is received from the timer.

I'm using timer 4 in auto-reload / compare / toggle mode for PWM output and it seems to be working correctly. The overflow and match interrupts are received by the ARM without issue.

I've read through the TRM to try and find more information regarding dma requests from the timers, but I'm not seeing anything besides table 20-3 in section 20.1.2.1.

What is the expected behavior regarding dma requests from the timers? How often should I be seeing them? Upon each interrupt or maybe just upon overflow? Where can I find more information regarding dma requests from the dmtimers?

thanks,
Patrick

  • 0
    Prodigy 60 points

    I've switched to using one of the eCAP modules in APWM mode and it triggers dma transfers just fine with my configuration.  

    I'm still stumped as to why the timer is not generating dma requests along with the interrupts going to the ARM.  I also tried using timer 7, but saw the same results.

    Has anyone else been able to trigger dma using one of the dmtimers on this chip?  I'd really like to figure out what is going wrong.

    - Patrick 

  • 0 in reply to Patrick Trantham
    Prodigy 130 points

    Hello,

    I have the same problem.

    The DMTimer4 triggers the DMA Interrupt only at once.

    In the DMA interrupt I execute the following steps:

    • Check: EDMA3_TIMER4_INT_EVENT == EDMA3IntrStatusHighGet(SOC_EDMA30CC_0_REGS) than
    • EDMA3ClrIntr(SOC_EDMA30CC_0_REGS, EDMA3_TIMER4_INT_EVENT);
    • EDMA3DisableTransfer(SOC_EDMA30CC_0_REGS, EDMA3_TIMER4_INT_EVENT, EDMA3_TRIG_MODE_EVENT);
    • TimerEDMAConfTransfer(EDMA3_TIMER4_INT_EVENT, EDMA3_TIMER4_INT_EVENT, <ReadBuffer>);
    • DMTimerIntStatusClear(SOC_DMTIMER_4_REGS, DMTIMER_INT_TCAR_EN_FLAG);

    Is this correct?

    After I had cleared the DMTimer4 interrupt flages, a new DMTimer event occured, but no DMA interrupt occured.

    Best regards

    Philip Hertweck

  • 0
    Intellectual 850 points

    Hello,

    I have the same problem.

    The DMTimer4 triggers the DMA request only at once.

    This is similar to a hardware error.                 How do you solve?                           Why TI employees did not pay attention to it?

    Vladimir.

  • 0 in reply to Vladimir
    Intellectual 850 points
    All DM timers behave so with DMA!
  • 0
    Genius 3685 points
    In order to get the next DMA event from Timer 4, you have to set up a second (chained) DMA transfer that do

    a) reset the DMA flag in the timer register set.
    b) reset the interrupt flag in the timer register set.

    Item a) is covered in the user manual. Item b) you have to discover yourself 8-(

    I have done DMA transfers via timer 4. It works (done this way)

    regards
    Wolfgang
  • 0 in reply to Wolfgang Muees1
    Mastermind 8040 points

    Wolfgang Muees1 said:
    a) reset the DMA flag in the timer register set.
    b) reset the interrupt flag in the timer register set.

    Not other way around? Normally I'd expect performing an EOI while an interrupt flag is still set to emit a new irq pulse. At least, that's how pulse-based irqs generally work, with the associated irq handler doing:

    • read irq flags, clear them if applicable
    • perform any appropriate actions
    • trigger EOI

    Once EOI is triggered, if any enabled irqs are still pending or subsequently become pending the peripheral again triggers once pulse. Basically the irq-pulse and EOI pass the ball back and forth of who is responsible of taking the next action. This type of irq handling tends to be more efficient than level-based irqs.

    Of course a DMA controller isn't an irq handler and normally DMA events fire without requiring any acknowledge, but evidently the DMTimer module has no native DMA output so they used the pulse-based irq output instead.

  • 0 in reply to Matthijs van Duin
    Mastermind 8040 points

    I've just tested, invoking EOI while an irq is active indeed emits another DMA event.

    The correct order is therefore as I assumed: clear irq, invoke EOI.

    If you want to minimize the chance a timer event is silently lost (especially in case the interval is particularly short and/or the transfer large or relatively low priority), clearing irq and invoking EOI should probably be done first. ("early" completion chaining can be used; as long as the clear-irq and EOI writes are submitted to the TC they are guaranteed to remain in the same order.)

  • 0 in reply to Matthijs van Duin
    Genius 3685 points

    Sorry, I have to correct myself: clearing IRQ flags comes first.

    In my implementation, I use no Timer Interrupt handler.

    I use a chained DMA channel, which is setting 2 Registers of the timer:

    1) IRQSTATUS = 0x07;      // reset all timer IRQ flags

    2) IRQ_EOI = 0x00;            // reset DMA flag

    I use DSTBIDX = (IRQ_EOI - IRQSTATUS). This is a negative offset.

    (I _love_ this DMA controller. You can do almost everything with it.)

  • 0 in reply to Wolfgang Muees1
    Prodigy 200 points
    Has anyone tried this on Linux?

    Regards,
    Amey Ghanekar