• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 97 subscribers
  • Views 402 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.

OMAP-L138 UPP Transmit Problem.

Michael Williamson
Expert 2005 points

Other Parts Discussed in Thread: OMAP-L138

Hi,

We've got an application using the OMAP-L138 UPP in duplex mode (one channel transmit 16 bit, one receive 16 bit).  The receive side is running at 20 MHz (external clock) and we aren't having any problems.  On the transmit side, if we run the system using the PLL0_SYSCLK2 (running at 150 MHz, yielding a 75 MHz output clock), everything works as expected.  We can divide down the clocks and the output rate drops accordingly. 

If we switch the Tx clock source to PLL1_SYSCLK2 (also set to 150 MHz), it works fine as long as we don't divide the clock down by more than a factor of 4 in the Tx Clock divider register in the UPP peripheral core.  If we divide down, we start getting EOR hits in the UPP Status register and transmitter stalls.

If we switch the Tx clock to source the external 2TXCLK pin, running at 40 MHz (for a net Tx clock rate of 20 MHz), we again get EOR hits and the Tx side stalls.

These tests don't change any code or other runtime operations outside of the Tx Clock selection in the SYSCLK3 register.  We're kind of scratching our heads here, as to why slowing the clock down would result in a transmit DMA EOR status.  The error mode seems to be related to the Tx Clock domain selection.  E.G., PLL0_SYSCLK2 can run at 75 MHz or any divided down rate without any EOR stalls, but if we switch to PLL1_SYSCLK2 using the same rates we have problems.  Same with the slower external clock.

Has anyone seen this?  We're going the our code again, but it seems odd that we'd be OK with one clock selection and fall over with a different (slower) one all else being the same.

Thanks.

-Mike

  • 0
    TI__Guru* 85175 points

    Mike

    What is your use-case that requires you to use PLL1_SYCLK2 or ext 2TXCLK as the source? Can you work with PLL0_SYSCLK2 as the source for your final application, since it seems to be working fine?

    lliamsonchael said:

    If we switch the Tx clock source to PLL1_SYSCLK2 (also set to 150 MHz), it works fine as long as we don't divide the clock down by more than a factor of 4 in the Tx Clock divider register in the UPP peripheral core.  If we divide down, we start getting EOR hits in the UPP Status register and transmitter stalls.

    Our upp expert is on time bank, so resolution might be slow, so if I understand you correctly , with DSP/ARM running at 300 MHz, PLL0_SYCLK2= 150 MHz ,

    Case 1

    CFGCHIP3.UPP_TX_CLKSRC= 0 and CFGCHIP3.ASYNC3_CLKSRC=0 , everything is fine, even if you increase the UPICR.CLKDIVn value 

    Case 2 

    CFGCHIP3_UPP_TX_CLKSRC = 0 , CFGCHIP3.ASYNC3_CLKSRC=1, works fine only untill you tweak the UPICR.CLKDIVn value to divide down the clock further

    Correct? No change in any other PLLx_SYCLKx settings, ARM/DSP/DDR speed? 

    Please also clarify what you meant by DMA EOR (i can't find this in uPP userguide) 

    Regards

    Mukul

  • 0 in reply to Mukul Bhatnagar
    Expert 2005 points

    Mukul Bhatnagar said:

    Mike

    What is your use-case that requires you to use PLL1_SYCLK2 or ext 2TXCLK as the source? Can you work with PLL0_SYSCLK2 as the source for your final application, since it seems to be working fine?

    This application is a coherent transceiver (ADC/DAC) system.  We need to use ext 2TXCLK at 40 MHz (the clock needs to be synchronous with the other UPP channel Rx Clock, at 20 MHz, we have external clocking circuitry generating these clocks to ensure coherency).  The PLL0_SYSCLK2 is not coherent with the signals we are trying to generate.  I only mentioned the PLL0_SYSCLK2 and PLL1_SYSCLK2 cases as they were used during experimentation .  We can ignore both of these use cases if you like and focus on the external Tx Clock.  The key thing is that PLL0_SYSCLK2 behaves differently than PLL1_SYSCLK2 (PLL1 is actually configured the same as PLL0, same clock speeds, etc., which is even more bizarre) and the external clock mode.

    lliamsonchael said:

    If we switch the Tx clock source to PLL1_SYSCLK2 (also set to 150 MHz), it works fine as long as we don't divide the clock down by more than a factor of 4 in the Tx Clock divider register in the UPP peripheral core.  If we divide down, we start getting EOR hits in the UPP Status register and transmitter stalls.

    Mukul Bhatnagar said:

    Our upp expert is on time bank, so resolution might be slow, so if I understand you correctly , with DSP/ARM running at 300 MHz, PLL0_SYCLK2= 150 MHz ,

    Case 1

    CFGCHIP3.UPP_TX_CLKSRC= 0 and CFGCHIP3.ASYNC3_CLKSRC=0 , everything is fine, even if you increase the UPICR.CLKDIVn value 

    Case 2 

    CFGCHIP3_UPP_TX_CLKSRC = 0 , CFGCHIP3.ASYNC3_CLKSRC=1, works fine only untill you tweak the UPICR.CLKDIVn value to divide down the clock further

    Correct? No change in any other PLLx_SYCLKx settings, ARM/DSP/DDR speed? 

    Please also clarify what you meant by DMA EOR (i can't find this in uPP userguide) 

    Case 1 and Case 2 descriptions are accurate.  DSP/ARM=300 MHz, PLL0_SYSCLK2 = 150 MHz, PLL1_SYSCLK2 = 150 MHz.

    Case 3 is the key case:

    CFGCHIP3_UPP_TX_CLKSRC = 1, generates the error immediately.

    The "DMA EOR" should have been:  The UORX bit (under or overflow condition) for the channel performing the transmit operation in the UPISR (section 33.3.8 of the TRM) is getting set.  Sorry for the confusion.  At the moment, we are ignoring this status bit with Case 3, and don't seem to be observing any data corruption issues, but we don't (yet) have good instrumentation set up to catch small losses of data in the DAC (tx) output waveforms being generated.  The concern is we don't think this bit should be firing, and changing the clock domain and running the interface slower should only help matters, we think....

    -Mike

  • 0 in reply to Michael Williamson
    TI__Guru* 85175 points

    I am not certain, but I wonder if there is some sort of a initialization/enabling sequence issue incase case 2 and 3 where the clock source is not from the same source as the upp module clock (PLL0_SYSCLK2). Would it be worth while to play with when the TX clock source is enabled vs when UPP peripheral/transfers are initialized etc?