Mity CPU Platforms » MityDSP-L138 (ARM9 Based Platforms)

Hi Marc,

If you are following the uPP design guidelines, then perhaps this is a true underflow or overflow condition. I have a number of questions about your project that can hopefully help us narrow down what the cause might be:

Are you using the Critical Link MDK drivers? If so, what version of the MDK are you using?

What is the CPU speed set to on the L138?

What uPP transmit clock set at?

How big are your uPP transmit buffers?

What are your uPP DMA and thread priorities set to?

What other peripherals are you using on your system that might be causing the uPP DMAs to stall?

Thanks,
\Greg

Hello,

Here are some answers to the questions:

• Are you using the Critical Link MDK drivers? If so, what version of the MDK are you using?
  - We use TI's legacy uPP driver
  - MDK_2013-05-15

• What is the CPU speed set to on the L138?
  - 300 MHz

• What uPP transmit clock set at?
  - 75 MHz

• How big are your uPP transmit buffers?
  - 128 Bytes ( 64 * 16 bits)

• What are your uPP DMA and thread priorities set to?
  - Thread prioity = 15
  - uPP DMA = ? (Default)

• What other peripherals are you using on your system that might be causing the uPP DMAs to stall?
  - DSP uses EMIF and uPP
  - ARM just runs linux from MDK_2013-05-15

Thanks for any assistants in this matter

Hi Marc,

Are you trying to run continuous transfers?

At 75 Mhz, you should be running a buffer rep rate of 64 / 75 MHz = 850 ns.

If you are trying to run continuous transfers, that would imply an interrupt rep-rate that fast.

You may also be seeing this if the DMA FIFO depth for the UPP is bigger than 128 words.

Do you get the error on every transmit, or periodically?

You might check the Bus Master Priority for the UPP DMA controller.

-Mike

Hello,

Here are some answers to the questions:

• Are you trying to run continuous transfers?
  - We do not run continuous but every 200 us (5 kHz)

• Do you get the error on every transmit, or periodically?
  - No not every transmit, lets say average once every 60 sec

• You might check the Bus Master Priority for the uPP DMA controller
  - will indeed check this. I be leave it is default 4

Thanks for any assistants in this matter

You might raise the priority up a bit (try 0 or 1). If the transfers are small, then it should be OK to give it priority.

-Mike

Hi Marc,

Here are a couple of other things to consider:

1. In the past we've had throughput problems with TI's uPP drivers. That was a couple years ago, so maybe the drivers are improved or will work fine for your scenario. However, if you continue having problems you may want to consider trying the drivers we wrote and distribute as part of our MDK.
2. The UPTCR control register for the uPP allows you to set the Transmit Threshold for the uPP channels. This controls how much data the uPP buffers before transmitting. It can be set to 64, 128 or 256 bytes. I'm not sure how this is set via the TI drivers, but you may want to look into what this value is set to since your transmit buffers are so small.

Let us know how things turn out.

Thanks,
\Greg

Hello,

Just a quick update. When we do not boot into linux (just uboot) we do not see
these errors.

So booting linux has somehow influence on the uPP performence.

Again thanks for any assistants in this matter

Did you check / adjust your UPP Bus master priorities?

Hello,

Yes we have adjusted the bus master priority of uPP, but did not see any great improvements (strangely).

We have tried to set the uPP clock div to 1 (so 37.5 MHz) and the errors were flying.

When you boot linux, are you changing the CPU OPP to 456 MHz or leaving it at 300 MHz?

We leave it at 300 Mhz