uPP bus error

Scott,

Are you developing your own uPP driver code?  If so, I recommend taking a look at the step-by-step procedure given in the uPP user guide to make sure you are setting up the peripheral and programming the DMA transfers in the correct order.

Also, could you provide more details on the specific error that you are seeing?  I would like to know whether this is a uPP error condition (ex. UOR or DPE) or a system error outside the uPP module.

Joe,

I am developing my own driver code.  I am following the procedure 2.6.1 in the uPP manual.  I am not setting up an ISR, but polling the UPISR.   I was just verifying I could run the uPP in loopback mode.  The error I was seeing was ERRI and ERRQ in the UPISR.  The DMA status registers had updated as I thought they should.  I decided to scrap my userspace driver and converted it to a kernel module.  I am now getting transfers from channel A to channel B.  I think my problem was passing a userspace memory address as the rx and tx DMA buffers.  I think the uPP needs kernel memory for those buffers?

I now have a new problem.  The transmit appears to have worked, the DMA registers update correctly, but my receive buffer only receives the lower 16 bits of the transmit buffer.  The receive buffer is full of the lower word.

Scott,

The uPP peripheral definitely needs physical addresses for its data buffers, so that explains your original issue.  The new issue is more mysterious to me.  Can you share the DMA parameters that you are using?  (line size, line offset, and line count)

Joe,

I wanted just a small buffer, so the line size is 0x40, line count 1, line offset: 0x40.  So this should be doing just 1 64 byte transfer.  Now after some tinkering with settings I was able to see the correct data in the receive buffer.  I originally had the clock divisor set for 0x0F.  When I made the divisor smaller the data in the receive buffer changed.  I finally set the clock divisor (UPICR-CLKDIVA) to 0 and the receive data was correct.  In digital loopback does the clock divisor setting matter?

Would it help if I posted my code?   thanks, Scott

Scott,

The clock divisor shouldn't matter in digital loopback mode.  I may need to do some tests on my end to see if we can reproduce this issue.

8171.upp.tar.gzJoe,

Thanks for your help.  That would be great if you could test this out.  I will attach my code.  It is currently set with a clock divisor of 0, so this is working.  If you change the divisor the rx buffer is then not correct.  It seems that the tx and rx are then on separate clocks.

8171.upp.tar.gzJoe,

Thanks for your help.  That would be great if you could test this out.  I will attach my code.  It is currently set with a clock divisor of 0, so this is working.  If you change the divisor the rx buffer is then not correct.  It seems that the tx and rx are then on separate clocks.

Joe,

I am trying to post my code so I apologize if this is a repost.  Your help is greatly appreciated I would like to know what is happening with my code.  The code I am posting has the clock divisor set to 0, and the rx buffer is as I expect.  When the divisor is set to anything else the rx is not working correctly.  It looks like the tx and rx data is clocked in at different rates.  thanks for your help, scott0028.upp.tar.gz

Scott,

That's an interesting observation.  The clock divisor for the receive channel should never matter, since in receive mode the CLOCK signal is an input.  For the sake of experimentation, please try the following configurations and let me know which ones fail in your application:

• Transmit and receive clock divisors both set to 0
• Transmit and receive clock divisors both set to 1
• Transmit divisor 0, receive divisor 1
• Transmit divisor 1, receive divisor 0

Joe,

I tried that this morning.  From the quick tests I did, it looks as long as both divisors are set the same the tx and rx buffers match correctly.  If the xmit divisor is set higher you see the rx buffer change according to the difference in divisors.  So if the tx divisor is set to 1 and the rx is set to 0 the data in the rx buffer is duplicated.  It looks like the rx clock is running 2x over the xmit clock.  If the rx divisor is higher then the xmit divisor I don't see any xmit data in the receive buffer.

I'm not really sure how much I will try and run this down since I'm only using this for a test.  There could be a clock bleeding onto the rx clock line on the my board.  I am using the Critical Link MityDsp L138 with the uPP, channels A and B, connected to a Xilinx Spartan 6 already.  I will post a question to the board manufacturers' at Critical Link to see if they have seen this before, and to test.  At the very least they can make a note of this.  Thanks for your help, Scott

Scott,

After some preliminary testing on our side, this may well be a previously undiscovered bug with the digital loopback mode.  I would not worry about it too much; this should not be an issue when you operate in a "normal" mode (i.e. data passing in or out through the actual pins).

Hope this helps.

Joe,

Thanks for taking a look at that.  At least there will be a note about this.  I'm not too worried about it for actual use, but I did have a question about the clocks.  We using Channel A to transmit to our FPGA, and channel B to receive data from the FPGA.  Our FPGA designer us using the Channel A tx clock to generate his tx clock for Channel B.  Can we use this?  I have no idea when the channel A tx clock is active.  Will it only be active when is has valid DMA descriptors?

thanks, Scott