• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 102 subscribers
  • Views 3233 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.

Using GPIO pin to trigger EDMA event

vikesfan
Prodigy 170 points
Other Parts Discussed in Thread: SYSBIOS

I am attempting to modify the StarterWare example "UARTEDMA_Cache" to have a GPIO pin initiate EDMA transfers on the BeagleBone target board.  In this case, I'm using GPIO1_31 as my input signal.  I am able to set up the GPIO pin as an input pin which triggers an interrupt on a rising edge.  I see that each rising edge opn the pin causes an interrupt.  I'm also configuring the EDMA3 controller to transfer data upon receipt of event 23 (GPIOEVT1) and upon transfer completion to link to another transfer request.  

After initialization,  I see the DMA performing the transfer on the first rising edge of the GPIO input, I get a Transfer Completion interrupt, and the PaRAM entries being updated for the next transfer request.  What is not happening is subsequent rising edges of the GPIO causing any more DMA transfers.

Examining all the EDMa registers after sebsequent GPIO rising edges, I don't see any of the Event Register, Secondary Event Register, or Event Missed Register bits being set.  It seems like the GPIO module isn't sending any more events to the EDMA module after the first one.  As mentioned above, the rising edges also cause an interrupt and I get interrupted on each edge ( the ISR clears the GPIO_IRQSTATUS register).

Looking through the TRM, I see some peripherals have DMA modes (i.e. UARTS) for interfacing with the EMDA but I don't see any mention of a mode(s) for the GPIO module.  Does anyone have any ideas?

  • 0
    TI__Intellectual 870 points

    Hi Vikesfan,

    Firstly apologize for the delayed response.

    In AM335x TRM, Table 25-2 says that “Interrupt Requests are redirected as DMA requests: 1 DMA request only for GPIO1 (GPIOEVT1) and GPIO2 (GPIOEVT2)”.

    Therefore for every rising edge on GPIO pin will generate an interrupt and the interrupt request will be redirected as DMA request. EDMA3 controller should be configured properly to handle the EDMA event.

    As you have mentioned, the first DMA event sent by GPIO has been serviced. You are also linking first EDMA PaRAM set with another. Could you please check whether this linking of EDMA PaRAM sets is proper?

    Please revert with your comments. 

    Thanks and Regards,

    M.Jyothi Kiran

  • 0 in reply to Madana Jyothi Kiran
    Prodigy 10 points

    Hello,

    I am having the exact same problem!  I am trying to do a simple RAM to RAM, AB-synchronized DMA transfer triggered by a GPIO pin.  I get the first frame to transfer on the GPIO rising edge, but subsequent transfers don't happen.  I have a callback on the GPIO interrupt and I print to the console at each interrupt.  So I can see that the GPIO interrupt is firing on each rising edge.  However the event doesn't seem to get through to the EDMACC after the first rising edge/interrupt.  I've also looked at the destination memory location and verified that only the first frame gets copied.

    In reference to PaRAM linking, from what I understand the link doesn't actually happen until the transfer is complete.  So this shouldn't be an issue until the entire AB transfer is done (there have been CCNT events).  But since the EDMACC is only seeing 1 event, we should never get to the point of linking.  Is this correct?

    Thanks for your help!

    P. Kim

  • 0 in reply to Madana Jyothi Kiran
    Prodigy 20 points

    Hi,

    I also hit the same problem yesterday. GPIO0 triggered DMA AB synchronised mem to mem transfer, no linking or chaining of further transfers, on a Beaglebone, in SysBios. The first time after reset that the interrupt is flagged in the GPIO module, the DMA transfer occurs correctly, after that the event will no longer appear in bit 22 of the EDMA event register.

    In order to get some code we could ship to the customer, I worked around it by manually triggering the DMA transfer in the GPIO ISR, however the customer is worried about possible latency/jitter incurred doing it that way, and would prefer the DMA event is triggered directly from GPIOEVT0.

    Is anyone looking at this?

    Thanks

    Ed

  • 0 in reply to Ed Langley1
    TI__Intellectual 870 points

    Hi,

    Firstly apologize for the delayed response.

    Could you please check whether linking of EDMA PaRAM sets is proper?

    Please refer the "mcasp" example, which is present in Starterware, to verify
    the linking of EDMA paRAM sets.

     

    Thanks and Regards,
    M.Jyothi Kiran

  • 0 in reply to Madana Jyothi Kiran
    Prodigy 20 points

    Hi Madana

    If you mean linking to another PaRAM set to start another transfer after the first one, I wasn't linking transfers when experiencing this problem.

    Or if you're referring to correctly mapping the channel to a PaRAM entry, I'm confident the mapping in the channel map was being set to the chosen PaRAM entry. I think this was proven because I could start the transfer manually by setting the event in the event set register and the transfer would occur correctly.

    Thanks

    Ed

  • 0 in reply to Ed Langley1
    Prodigy 50 points

    Hi,

      Would you share how to solve the problem?  A DMA event completed but don't write 0 to GPIO_EOI.DMAEvent_Ack caused the problem?

      Your reply will be appreciated.

    Thanks

    Best regards,

    qzl