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.

OMAP-L138 uPP DMA



I'm using the OMAPL-138 uPP port to send data out to an external device using its dedicated DMA. I've noticed that there's some seemingly false start and enable pulses prior to the real starts and enables which are accompanied with my data.  I can build logic in the external device receiving the data to ignore these first false pulses, however, I'd like to know if these are expected and need to be accounted for.  The UPP User's Guide does not mention anything about this, Figure 10. depicts that the start and enable pulses are accompanied with data at all times.   

  • Joe,

    Are you using the uPP BIOS driver, or are you using your own low-level code to program the peripheral?  If you're using your own code, please check to make sure that you are following the steps (in order) specified in the user guide.

    Also, how often do you see false start and enable pulses?  Does this only happen once during initialization, or does it keep happening at run time?

    I'm sorry to respond with so many questions, but I'd like to get a better idea of your use case.

  • I'm using my own low-level code to program the uPP control registers.  I only see the false pulses at initialization, I do not see false pulses during or after the real pulses with data. 

  • Perhaps have a colleague review your code to make sure it conforms to the initialization procedure in the UPP guide.  You can post your code here if you'd like too.  Maybe me or Joe C can have a look.

  • I took another look at this while I was running some other uPP tests, and I found what may have caused the appearance of false enable/start pulses.  If the uPP pinmux is applied before the peripheral is enabled (i.e. when UPPCR.EN = 0), the control signals either drive or float high.  When the peripheral is enabled (UPPCR.EN = 1), these signals will go low again (assuming they are not inverted in UPICR).  Thus, if you observe the pins during initialization, it may look like start/enable pulse high momentarily before any transfers take place.  It could also happen again, later, if the peripheral is disabled again by clearing UPPCR.EN.

    This shouldn't necessarily be a problem, but it is something to be aware of.