• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 101 subscribers
  • Views 1073 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

uPP Transmission Problems (UOR Error on DMA Channel I)

Gregory Gluszek
Prodigy 200 points
Other Parts Discussed in Thread: OMAPL138

 

Hello,


I’m having trouble with uPP Transmit. I have Channel A configured for 16-bit transmits using DMA I and I'm using an OMAPL138 running at 300 MHz. I have my test code stripped down to a loop in which I perform a single transmit, wait for the interrupt indicating that the transmit has completed and then repeat. The issue I’m seeing is that I very frequently get UORI interrupts from the uPP device.


I’ve gone through all the suggested actions in section 2.6.3 of the uPP User’s Guide (using single data rate, increasing the clock divisor to its maximum, changing the DMA read burst size to 256, using longer lines (up to 0xFFFE bytes), and raising the system priority of the uPP DMA to its maximum), but I still see the UORI error.


The only way I can make the error go away is to decrease the byte count setting in the DMA control registers to be less than 256, and then increase the line count so that the desired number of total bytes is transferred. I realize this is the opposite of what the User’s Guide advises, but for some reason it stops the UORI error from being generated. For example, if I want to transmit 1280 bytes, setting the byte count to 1280 and the line count to 1, will generate UORI errors. However setting the byte count to 128, the line count to 10 and the line offset to 128 will not generate any errors.


Is this perhaps somehow related to the 2xTxClk required for uPP transfers? I’ve tried a variety of clock speeds, and have used the clock divider for Channel A to set the Tx Clock to be exactly half of 2xTxClk or even much slower, but it does not seem to make a difference. Are there additional requirements for the 2xTxClk? All I’ve read in the User’s Manual is that it must be twice the frequency of the Tx Clock.


Here is a copy of the uPP configuration register settings I’m using (in case it helps):

1651 1 1e16000 0 78

0x44231100 UPPID

0x00000089 UPPCR

0x00000000 UPDLB

0x00000000

0x22220007 UPCTL

0x00300130 UPICR

0xFFFFFFFF UPIVR

0x03030303 UPTCR

0x00000010 UPISR

0x00000000 UPIER

0x00000F0F UPIES

0x00000F0F UPIEC

0x00000000 UPEOI

0x00000000

0x00000000

0x00000000

0xC6120080 UPID0

0x00010100 UPID1

0x00000000 UPID2

0x00000000

0xC6120080 UPIS0

0x00020000 UPIS1

0x00000020 UPIS2

0x00000000

0x00000000 UPQD0

0x00000000 UPQD1

0x00000000 UPQD2

0x00000000

0x00000000 UPQS0

0x00010000 UPQS1

0x00000020 UPQS2

 

Any help or insight would be greatly appreciated.

 

Thanks,

\Greg

  • 0
    TI__Expert 8890 points

    Gregory,

    You only need to worry about 2xTXCLK if you have configured the CHIPCFG registers to use that pin to provide the (2x) transmit clock for your uPP transmit channel.  (See section 7.3.5 of the System Reference Guide for more information.)  When using 2xTXCLK, the only requirement is that the input clock speed cannot exceed 150 MHz.  The clock will be divided by 2 (to reach 75 Mhz) then divided again by the clock divider that you specify in the UPICR register.

    Please note that 2xTXCLK is an optional signal.  By default, the uPP peripheral uses PLL0 SYSCLK2 instead of 2xTXCLK.

    The issue that you are reporting with UORI events is not something that I have encountered in my tests.  I find it particularly interesting that you see the same behavior even when you slow down the uPP transmit clock (i.e. set the clock divider higher).  If you are using 2xTXCLK, what clock speed are feeding to that pin?  If it's higher than 150 MHz, that could explain the issue.

    Hope this helps.

  • 0 in reply to Joe Coombs
    Prodigy 200 points

    Joe,

     

    Thanks for the quick response. You were right that 2xTxClk was not being used, however instead of using PLL0_SYSCLK2 my system was configured to use PLL1_SYSCLK2 for the transmit clock. I switched to using 2xTxClk (150 MHz) and I no longer see the error.

     

    Thanks for the help!

    \Greg

  • 0 in reply to Gregory Gluszek
    Prodigy 160 points
    Hi Joe, I am working on upp driver in linux kernel. I have configured upp in loopback mode CH_A (TX) and CH_B (RX) mode.I am not getting data at all. Could you please help on the issue. What will be the value on D[0-15] pins when channel is jst configured? How can I tap the signal on Data pins? Could you please let me know any debugging method for this. Thanks, Mrudula