c6748 UPP operation

Fred,

Your uPP configuration looks fine to me.  I see that you are not using the START and ENABLE signals, which should be valid in receive mode as long as you only run the clock signal during transfers.  Could you share the transfer parameters (line size, count, offset) that you are using in this test?

Also, I want to check that you are programming the transfer in the DSP application (i.e. calling SIO_issue) before the FPGA initiates the transfer.  In receive mode, it's important that the peripheral know what to do with incoming data before it starts to arrive.

Hope this helps.

Unfortunately, I am a hardware engineer with very little experience with the software tools. I don't know where to find SIO_issue, and I am having some trouble following the code execution order. 

I did notice Dave Chen's Posts "UPP DMA Starts Early" that you spoke of inverting the clock in the ICR register. 

To test that, I redid my FPGA to set the default value of the clock high.

I still miss the first 3 or 4 words (16 bits) of the first transfer out of the UPP interface.  I have monitored the UPP lines with a scope (CLock, and the first 3 data bits).  All the levels, setup and hold times, etc. look good on every data frame.

I am kind of at a loss on how to proceed.  I really have no access to the chip internals to watch what is happening in the UPP itself.  This is my first inclination, being a hardware type.

Fred,

Can you try to delay initiating the transfer from the FPGA until the application has been running long enough to block waiting for the incoming data?  I want to be sure that you are not sending data to the uPP peripheral before it's ready to receive.

Also, if you only ever send one frame of data from the FPGA, does the transfer complete on the DSP?  You mentioned that data seems to "wrap around" the buffer, but I am wondering if that could be an illusion caused by successive data frames arriving from the FPGA, i.e.:

First Buffer (x):   Second Buffer (y):
    [ x3 ]              [ y3 ]
    [ x4 ]              [ y4 ]
     ...                 ...
    [ xN ]              [ yN ]
    [ y1 ]              [ z1 ]
    [ y2 ]              [ z2 ]

In the above, the DSP missed the first few samples of the first buffer (x) and filled in its remaining samples with values from the second buffer (y).  Since we're not using the START signal, this can happen without triggering an error condition.

the app has been running for a few seconds (maybe even minutes) before I send data. 

We are using ethernet to view the data.  The dsp sends an ethernet pakcet every 1152 bytes of data from the UPP.  If the Ethernet buffer is not full (1152 bytes) the data is not sent.

Data is a 16 bit word that counts up from 1.  At the beginning of each data set, the data again starts at 1.

When I send 1 frame from the FPGA, no ethernet packet is sent.  When I send the next frame, (beginning of the next data set) the ethernet packet is sent.  The first word (16 bits) of data in the ethernet buffer will usually be 4.  This will count up to 576 and then restart at 1,2,3 etc.

What appears to be happening is that the UPP is not receiving the first few words of data in the first frame. (it is not wrapping, it just appeared to be doing that in earlier tests)

The fact that I see 1,2,3 to 576 (eventually) leads me to believe that my clock and data from the FPGA to the DSP is OK.

I also have questions on the hardware. 

In the receiving UPP interface what exactly does START do? (from the sending interface, it indicates the beginning of a DMA line)?

In the receiving UPP interface what exactly does ENABLE do?

Fred,

When using the START and ENABLE signals, it's OK to feed the uPP a constantly active clock signal.  Data is only accepted while ENABLE is asserted.  START is only active during the first word of each DMA line.  It's also acceptable in receive mode to use ENABLE but not START.  You can find more information about these signals (including timing diagrams) in the uPP user's guide.

• http://focus.ti.com/lit/ug/sprugj5b/sprugj5b.pdf

The uPP protocol is more robust while using ENABLE and START, so you may want to consider adding those signals if your problem persists using clock only.

I understand what the UPP UG says.  However, I am asking for more details.  The UPP UG only describes these signals in terms of the driver, not the receiver.  I am guessing that the UPP receiver uses the ENABLE signal something like the enable pin on a 7474 ff.  However, how start is used is not at all clear or apparent.

As I am creating a UPP driver from an FPGA that has no concept of DMA line size, it would be helpful to know what the START signal does in the receiver before I start pulling my hair out over it.

I spoke with our software/systems engineer.  We are using your app code with only the start and enable configuration changed.  Based on the data sheet, I should not have a problem (in the hardware) using only clock and dated.  The clock is only available when I am transferring data.

Joe,

The parameters are bytesPerLine = 1152, linecount = 1, lineOffset = 0.   I cribbed the code from your EvmA/B examples and tested it with two Evm kits.

Thank you

Mitch

I ran some UPP tests using two EVMs.  One EVM is configured as a UPP Transmitter.  Every 'Frame' it counts up from 0 to 576 for a total of 1152 bytes, 2 bytes to a word.

The receiver sends the complete 1152 byte frame to a PC running linux.  There is an extra byte, the first byte in the Ethernet frame, that identifies the number of the frame sent.

Results:

1) disable start on the receiver:  The system operated perfectly with clock and enable.

2) Gate the clock with the Transmit 'Enable' and disable 'Enable' on the receiver:  After accounting for un-equal delays in for clock and data through the gate (data is not gated) by inverting the clock on the receiver,  you can see the results in the attached file.  What appears to be happening is the first 302 data sets are being missed and the data from the next 'frame' is being appended to the buffer to complete the Ethernet message.  A similar thing is happening in my FPGA App.  The difference is the clock speed (45MHz in the FPGA vs 10 MHz in the EVMs) and bursty data in the FPGA (48 words, 96 bytes, at a time instead of one continuous output in the EVMs).  In my FPGA APP, the first 3 bytes are missing and appended from the next 'frame'.

Also included is the EVM UPP setups for the test.

Sorry.  It seems I forgot to attach the files.  Here thay are.

There are two files that show the gated clock, on at the beginning of the cycle (ALL0010\F0010.BMP) and on at the end (ALL0011\F0011.BMP).  The Transmit Enable signal is used for reference.  Clock is the blue trace and Enable is the orange trace.

UPPRxConfig.txt contains values in the record Upp_ChanParams for the receive Eval unit and UPPTxConfig.txt contains values in the record Upp_ChanParams for the Transmit Eval unit.  UPPGatedClockNoStartData.txt contains the test results.  It should be open in wordpad or something like it.  A plain text editor, such as notepad will likely be unreadable.

8540.UPPTest.zip

In this design, I was running out of pins on my FPGA.  Because the data sheet led me to believe I did not need start and enable, I did not route them

On the next spin I will, but I will sacrifice 8 data bits on the emifa interface to be able to do this.

I used a jumper to get to the enable pin.  Everything appears to be working now.