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: OMAP-L138: Unstable uPP DMA transfer

Part Number: OMAP-L138

Hello, dear TI, 

I would like to re-enable our discussion on this topic. I'm sorry I haven't answered in some normal period.. Our discussion has been locked in the thread: e2e.ti.com/.../654447

Our application is programming uPPA and uPPB channels to receive periodically blocks of 4096 samples @ 1 msec rate.

The uPP configuration is dual channel Rx mode, 8-bit mode for uPPA, 16-bit mode for uPPB, Enable and Start signals enabled, Wait signal omitted, Clock signal is continuously generated by FPGA.

Even though the uPP peripheral was initialized following the step-by-step procedure described in the TI reference manual, unstable DMA transfers are observed over reset cycles such as either missing DMA transfer for one or both channels, or DMA transfer not synchronized between channels.

Is there any known issue on that topic?  What kind of help TI can provide to help debugging the issue?

We found question related to providing uPP clocks during initialization sequence in https://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/639/t/372349?tisearch=e2e-sitesearch&keymatch=upp%20clock

Could missing uPP clock signal during initialization cause similar issues to ours? (i.e unstable DMA transfers)

Note that we perform initialization of uPP peripheral according to step-by-step procedure (steps 1-7) during an application startup and programming of DMA transfer (steps 8-10) in the end of startup when everything should be prepared to start uPP receiving. 

Further details, based on the previous discussion, are:

  • We don't use any SDK. we have developed our own low level drivers for all peripherals.
  • Clock speed is 4.36 MHz.  We can’t lower the clock.

  • Please further clarify what you meant here "unstable DMA transfers are observed over reset cycles such as either missing DMA transfer for one or both channels, or DMA transfer not synchronized between channels." Is the failure only happening when you try the test with reset/restarting the application, does it fail every time or sporadically during this reset test?
    • Once the uPP is programmed and receiving data, the samples on the I and Q DMA channels are not received at the same time.  Sometime the data on one of the channel is even missing.  The failure mode varies over unit, either consistent or sporadic.
  • Can you elaborate here, so is the the Step 2 for you that the module clock via PSC is enabled, but the transmit clocks that are sourced by the FPGA not on at this time? Can you change this to try if this makes a difference?
    • It is not easy to modify the FPGA to control the uPP received signals.  We were hoping TI could provide more details on possible cause before undertaking more debugging effort in changing the FPGA firmware.

Thank you for your help,

Karel

  • The team is notified. They will post their feedback directly here.

    BR
    Tsvetolin Shulev
  • Hi Karel,
    Sorry for the long delay but our expertise on uPP is very limited. Can you provide more detail on the failure observed and how it relates restarts. It sounds like you are initializing two asynchronous DMA transfers using two separate uPP channels. You mentioned that the DMAs were unstable over reset cycles but I didn't see any detail on what type of reset you were generating. Are you referring to a device reset of some type, a reset of the uPP module within the device or some sort of cancellation of an ongoing transfer.
    Is this issue only associated with the situation where two separate DMA channels are operating? If you are only using a single uPP channel with DMA, do you observe the same instability?
    You mentioned that you are not using processor SDK. Have you developed an independent low level test program to check the uPP interface? This would be an attempt to determine whether this is a DMA problem within the part or the result of an unstable connection between the FPGA and the SoC.
    Regards, Bill
  • Hi Karel,
    We haven't heard from you in awhile. I will close this thread. You can reopen it if necessary.
    Thanks, Bill