2009-09-24 06:25:36     BF548 EPPI revisited

Document created by Aaronwu Employee on Aug 26, 2013
Version 1Show Document
  • View in full screen mode

2009-09-24 06:25:36     BF548 EPPI revisited

Martin Strubel (SWITZERLAND)

Message: 80371   

 

Hello,

 

After dropping the BF548 EZKIT about a year ago for video processing due to partial signal integrity issues (see also thread   blackfin.uclinux.org/gf/project/uclinux-dist/forum/?_forum_action=ForumMessageBrowse&thread_id=31033&action=ForumBrowse&forum_id=39) I'm revisiting video acquisition again on a different BF548 platform where signal traces are way better.

 

This time I'm no more seeing random errors, but a consistent number of H overflows (LTERR_OVR set in PPI_STATUS), which matches the number of lines exactly. I've written to processor.support@analog.com in parallel, see below:

 

-------

 

The setup: Micron MT9P031 sensor with the timing shown in

default-timing.png.

 

My EPPI1 values:

 

VCOUNT  : 1944

HCOUNT  : 2592

FRAME   : 1944

LINE    : 2592

HDELAY  : 0

VDELAY  : 0

CONTROL : 1810002c

[RECEIVE] [ITU_INTERLACED] [POLC: 0] [POLS: 0] [DLEN: 8] [PACKEN]

[FIFO_RWM: 3][FIFO_UWM: 0]

STATUS  : 0000

 

I have a ppi error interrupt installed that counts all tracking errors.

 

What I am observing:

 

1. The frame comes in ok, but I get exactly `FRAME` tracking errors

(LTERR_OVR from PPI_STATUS set) i.e. 1944 per frame.

2. If I turn on "Continuous LINE_VALID" on the sensor as shown in

lval-timing.png, I get FTERR_OVR errors as well. This suggests, that the

EPPI does not like FS1 pulses within the vertical blank. Can you confirm

that?

 

I have also verified this behaviour previously with a video generator

which generates a known timing, but continuous FS1 (Line valid). POLC

and POLS are set appropriately.

 

Questions:

 

a) Does the EPPI expect a timing where the pixelclock is gated (i.e.

inactive) during FS1 blanks in order not to throw LTERR_OVR errors?

b) According to the HRM, the Blanking registers do not matter in RX

mode. Can someone confirm this?

 

-------

 

It seems like everyone playing with the EPPI is ignoring errors (at least the people I talk to).

 

Is there anyone who could tell me I'm plain stupid, or has made similar experiences?

 

BTW, I'm running at a very low PPICLK of 6 MHz and tested things 'standalone' to eliminate possible cache /DDR anomaly issues with < 0.2 silicon.

 

Greetings,

 

- Martin

QuoteReplyEditDelete

 

 

2009-09-24 06:28:59     Re: BF548 EPPI revisited

Martin Strubel (SWITZERLAND)

Message: 80372   

 

I should have attached the timing diagrams...

 

lval-timing.png

default-timing.png

QuoteReplyEditDelete

 

 

2011-05-06 07:18:42     Re: BF548 EPPI revisited

Marius Kotsbak (NORWAY)

Message: 100485   

 

Hi!

 

We are also trying this setup and see the same problem. Did you solve the issue? Also see my bug report: https://blackfin.uclinux.org/gf/project/uclinux-dist/tracker/?action=TrackerItemEdit&tracker_item_id=6543&start=0

Attachments

Outcomes