2009-04-13 07:32:53 PPI under run Error

Ashish Gupta (INDIA)

Message: 72584

Hi,

I am trying to use the ppitest.c from /uclinux-dist/user/blkfin-test/ppi-test to use the PPI port to send image data to a FPGA.

But I get a PPI ERROR - PPI STATUS 0x2000. which corresponds to UNDR (FIFO Underrun) error.

I am new to the uClinux world and less sure about whether my usage of the bfin_ppi driver and the ppitest.c test program is correct. What step am I missing?

Following are the details of my experiment : -

Just made one change by commenting the CFG_PPI_PORT_DIRECTION & CMD_PPI_PACKING in the ppi-test.c file

CfgTable ppiMasterTable1D[] = {

// { CMD_PPI_PORT_DIRECTION, CFG_PPI_PORT_DIR_TX }, // write

// bfin_ppi does not support this command now, this is

// automatically taken care of while reading/writing

// { CMD_PPI_PACKING, CFG_PPI_PACK_DISABLE },

{ CMD_PPI_SKIPPING, CFG_PPI_SKIP_DISABLE },

{ CMD_PPI_SKIP_ODDEVEN, CFG_PPI_SKIP_ODD },

{ CMD_PPI_DATALEN, CFG_PPI_DATALEN_14 },

{ CMD_PPI_CLK_EDGE, CFG_PPI_CLK_EDGE_RISE },

{ CMD_PPI_TRIG_EDGE, CFG_PPI_TRIG_EDGE_RISE },

{ CMD_PPI_XFR_TYPE, CFG_PPI_XFR_TYPE_SYNC },

{ CMD_PPI_PORT_CFG, CFG_PPI_PORT_CFG_SYNC1 },

{ CMD_PPI_SET_DIMS, CFG_PPI_DIMS_1D },

{ CMD_PPI_DELAY, 0 },

{ CMD_PPI_GEN_FS12_TIMING_ON_WRITE, 1 },

{ 0, 0 }

Screen dump: -root:/home> ./ppi_test m

fd(3) = open(/dev/ppi)

Enter Line length (default = 16):

Enter number of lines (default = 8):

beMaster()

Setting up master...new gImageSize( 1659004 ) = 0x100 (256)

Master set up complete...further input is transmited to slave

Enter fill pattern [CcQqRrTtVvHh?]: c

fillBuffer(165900PPI Error: PPI Status = 0x2000

PPI Error: PPI Status = 0x2000

1 2 3 4 5 6 7 8 9 A B C D E F 10

Enter fill pattern [CcQqRrTtVvHh?]:

I've connected a the 25MHz CLK_BUF to PPI_CLK.

QuoteReplyEditDelete

2009-04-14 10:19:08 PPI under run Error

Michael Hennerich (GERMANY)

Message: 72638 Just to see if it makes a difference...

Can you try a slower ppi clk (12MHz for example)?

-Michael

QuoteReplyEditDelete

2009-04-15 12:33:03 Re: PPI under run Error

Ashish Gupta (INDIA)

Message: 72704

Thanks for the suggestion Michael,

I tried the same with different clock settings, this time round I ran the app for PPI DATA Length to be 8 wide. I checked the status of the PPI registers (CONTROL, FRAME, COUNT, STATUS) using debug MMRs utility after starting the program and those were all setup correctly.

I ran the tests with different PPI_CLK values and got mixed results, in some cases i got a perfect HSYNC/VSYNC for a particular PPI_CLK but not reliably, for other PPI_CLK values I always got a PPI under run error, with PPI_STATUS register = 0x2000.

Also one very peculiar thing, for PPI_CLK = 25MHz if I use the telnet terminal (over ethernet) instead of the serial terminal, I got no PPI errors and perfect HSYNC / VSYNC waveforms. While with same setup when I use the serial terminal, I ger the PPI under run error.

Any clue what's happening?

I need to keep the PPI_CLK at 23 - 25 MHz as I will be using the PPI to interface to a ADV7125 video dac -> PC monitor. The Blackfin PPI lines will be connected via an FPGA to the ADV7125 digital inputs.

Results for different PPI_CLK with Serial terminal: -

10MHz - Always PPI under run error

12.5 MHz - Always PPI under run error

14.2857 MHz - 1/2 times

16.667 MHz - 1/2 times PPI under run error

20 MHz -1/2 times PPI under run error

25 MHz -Always PPI under run error

Results for different PPI_CLK with Serial terminal: -

10MHz - Always PPI under run error

12.5 MHz - Always PPI under run error

14.2857 MHz - Always PPI under run error

16.667 MHz - Always PPI under run error

20 MHz -Always PPI under run error

25 MHz - seems to be working fine, no PPI error

Thanks & regards

Ashish

P.S.: your paper titled "uClinux on the Blackfin DSP Architecture" was really helpful for getting upto speed on blackfin uclinux

QuoteReplyEditDelete

2009-04-16 03:32:18 Re: PPI under run Error

Michael Hennerich (GERMANY)

Message: 72726 Ashish,

What you describe sounds odd to me.

And I'm trying to recreate what you are seeing.

You said that the only thing you changed was CFG_PPI_PORT_DIRECTION & CMD_PPI_PACKING?

In ppiMasterTable1D?

The test app uses DIM2D by default so you should do those changes in ppiMasterTable2D.

Or did you also change the app to use 1D DMA?

-Michael

QuoteReplyEditDelete

2009-04-16 10:53:51 Re: PPI under run Error

Ashish Gupta (INDIA)

Message: 72759

Hi Michael

I am using 2D DMA only, I did following 2 changes in the ppiMasterTable2D: -

1. Commented out

{ CMD_PPI_PORT_DIRECTION, CFG_PPI_PORT_DIR_TX }, // write

as the new bfin_ppi.c driver does not have this ioctl command and automatically sets direction in Read/Write calls -

2. Commented out

{ CMD_PPI_PACKING, CFG_PPI_PACK_DISABLE }

as the new bfin_ppi.c driver does not support this call.

I've also added code (see attached file : ppitest.c line#312 - line #337) to setup PF5 and PF6 high as these pins control the directionality of the buffers through which the PPI lines on our board goes to the connector.

Hardware: Bluetechnix CMBF537E module mounted on our custome carrier board which brings out PPI via buffers to a connector.

Software: uClinux built from trunk distribution. .config file is attached

config

ppitest.c

bfin_ppi.h

QuoteReplyEditDelete

2009-04-16 11:47:32 Re: PPI under run Error

Michael Hennerich (GERMANY)

Message: 72761 Ashish,

I tested the ppi driver with the ppi-test application this morning.

And I don't see such things happening. (PPI CLK = 12.288MHz)

Tomorrow will see if I can find a DDS board to generate different frequencies.

My function generator stops at 10MHz...

-Michael

QuoteReplyEditDelete

2009-04-17 10:45:36 Re: PPI under run Error

Ashish Gupta (INDIA)

Message: 72782

Hi Michael,

If PPI doesn't work out for me, I was thinking of alternatives.

The Objective is to move image data into the FPGA to which a video DAC is connected (ADV7125). We also bring the EBIU AMC interface to the FPGA and since the CMBF537E module brings out upper 2 AMS lines, theoretically we should be able to send the data over to a matching digital block in the FPGA.

What would be the best way (which Driver/app/test code available in uClinux) to send over images using DMA to the EBIU Asynchronus interface. (assuming the digital block we make in the FPGA will behave as a SLAVE for the Blackfin EBIU AMC).

Regards

Ashish

QuoteReplyEditDelete

2009-04-20 07:19:42 Re: PPI under run Error

Michael Hennerich (GERMANY)

Message: 72863 Such an approach is technically not a problem. However I wouldn't run

for it, since it is suboptimal from a memory interface utilization point

of view.

You would read something from SDRAM and then write it to an Interface

(EBIU) physically shared with the SDRAM interface.

This kills a lot of performance.

PPI is the interface you want to use.

We have several drivers' use this interface with TFT displays, CMOS

Camera sensors, FPGAs and external video encodes/decoders.

Here some examples we know they work without PPI underrun or overflow

issues:

ADV7393 Video Framebuffer: 13.5 MHZ over an 16-bit PPI.

MT9M001 CMOS Camera: 40 MHZ over an 8-bit PPI.

t350mcqb TFT Framebuffer: 12 MHZ over an 8-bit PPI.

What is the minimum PPI clock you would need?

-Michael

QuoteReplyEditDelete

2009-04-20 10:36:46 Re: PPI under run Error

Mike Frysinger (UNITED STATES)

Message: 72889

using the UART often results in higher overhead than using the network and thus ties up the system from being able to respond to PPI

QuoteReplyEditDelete

2009-04-21 11:51:28 Re: PPI under run Error

Ashish Gupta (INDIA)

Message: 73003

Hi Michael,

There are two goals : -

1. Interface the Video tripple DAC ADV7125 with the Blackfin PPI in 565 parallel mode

We plan to use the PPI to send VGA image to the ADV7125 @ 24 MHz clock for supporting VGA resolution @ 60 Hz refresh rate supported by most Monitors.

So i am afraid we may not be able to use the following as they seem to be slower : -

ADV7393 Video Framebuffer: 13.5 MHZ over an 16-bit PPI.

MT9M001 CMOS Camera: 40 MHZ over an 8-bit PPI.

t350mcqb TFT Framebuffer: 12 MHZ over an 8-bit PPI.

Any ideas? Is there a generic Frame buffer driver that can be used instead of the bfin_ppi.c driver.

2. An interace to send over image data to FPGA over PPI

For this I guess we can use one of the other ones, also could you please point me to the PPI driver for interface with FPGAs you mentioned above.

Thanks & regards

Ashish

QuoteReplyEditDelete

2009-04-22 04:30:46 Re: PPI under run Error

Michael Hennerich (GERMANY)

Message: 73050 >There are two goals : -

>1. Interface the Video tripple DAC ADV7125 with the Blackfin PPI in 565

parallel mode

>We plan to use the PPI to send VGA image to the ADV7125 @ 24 MHz clock

for supporting VGA resolution

>@ 60 Hz refresh rate supported by most Monitors.

>So i am afraid we may not be able to use the following as they seem to

be slower : -

>ADV7393 Video Framebuffer: 13.5 MHZ over an 16-bit PPI.

>MT9M001 CMOS Camera: 40 MHZ over an 8-bit PPI.

>t350mcqb TFT Framebuffer: 12 MHZ over an 8-bit PPI.

I know there have been people interfacing the ADV7125 directly to the

Blackfin PPI for exactly this reason. (Drive VGA RGB CRTs and TFTs)

This should work on a BF561 without problems due to the 2x Memory

Bandwidth compared to a BF52x, BF53x or BF51x.

It will also work without problems as long as you don't use the SDRAM

for anything other than storing the framebuffer in memory.

In Linux you are forced to do external code execution from SDRAM, this

can cause PPI under-run errors under certain conditions.

>Any ideas? Is there a generic Frame buffer driver that can be used

instead of the bfin_ppi.c driver.

The bfin_ppi.c driver shouldn't be considered at all for such an

application. The bfin_ppi.c driber is amined to do single shot transfers

from userspace (maybe used to send some data to an FPGA for other

reasons).

There are various Blackfin Framebuffer drivers under drivers/video.

They all can be used as an example.

The ADV7393 for example drives a S-VIDEO out or Composite out for NTSC

or Pal TV resolutions. The Framebuffer format is RGB565.

The ADV7393 Encoder Card also features a VGA Connector - however it

turned out that the RGB OUT mode on the ADV7393 doesn't except RGB565

inputs.

http://docs.blackfin.uclinux.org/doku.php?id=hw:cards:adv7393

If you are really looking for VGA or SVGA type resolutions with 60HZ and

more update rates, you should consider using an external Display

Controller such as the EPSON S1D13706 or similar.

There are Linux from EPSON drivers available. These controllers are

connected to the Blackfin External Memory Bus. The major advantage is

that you constant Video update comes from an external Video RAM(SDRAM)

and not from the Blackfin external SDRAM.

>2. An interace to send over image data to FPGA over PPI

>For this I guess we can use one of the other ones, also could you

please point me to the PPI driver

>for interface with FPGAs you mentioned above.

Take a look at uclinux-dist/user/blkfin-apps/fpga.

This driver was also only targeted to make single shot transfers.

-Michael

QuoteReplyEditDelete

2009-04-30 15:29:00 Re: PPI under run Error

Michael Hennerich (GERMANY)

Message: 73492 I took some time yesterday and today to root cause these. They are

definitely NOT caused by bandwidth limitations.

- Still think PPI should be your preferred choice.

The underrun errors are actually caused by the fact that the framesync

FS1 asserts immediately again after the last payload word is

transferred.

Since there is no DMA active to provide more date the PPI will assert

the UNDERRUN condition.

By default the PPI_ERROR interrupt has higher priority than the DMA

(DONE) Interrupt therefore you will se the PPI error interrupt

asserting, even when all words are properly sent out...

1) lower the PPI ERROR interrupt priority, below the IRQ_PPI.

OR (and)

2) Odd some timer delay between FS1 assertions (Will add some duty cycle

option to the bfin_ppi driver to control this.

Best regards,

Michael

Partner Forums

Partner Libraries

2009-04-13 07:32:53 PPI under run Error