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
