Posted on

Blackfin EPPI research

BF54x EPPI timing tests

This test report investigates the erroneous behaviour of the EPPI in General Purpose video mode.


Sensor output:

Image 8×2, 8 bit testpattern (Bayer, fixed values), 8 bit data.

The Test pattern has the values:

          0  1  2  3  4  5  6  7  [ Column ]
Row 0:   1E 0D 1E 0D 1E 0D 1E 0D
Row 1:   0B 1E 0B 1E 0B 1E 0B 1E

etc.

Timing:
See lval8.png: yellow: FS1, blue: PPI_CLK

Line valid signal

See fval8.png: yellow: FS2, blue: FS1

Frame valid signals

Note that this timing was changed to 2 (two) lines only for the test report below.


Test program:

  • Checks for PPI_STATUS errors
  • Checks DMA errors
  • DMA 32 bit transfer mode is used with PACK_EN bit on EPPI set
  • Uses Snapshot mode to get exactly 1 image (to prevent overruns from subsequent images)
  • On reception of a frame, an IRQ is triggered and a status flag is set to indicate a valid frame. If the IRQ is not called within a certain timeout period, the frame acquisition exits.
  • Memory buffer is cleared before receiving a frame
  • Does a memory dump of the received frame

TESTS

Markups:
#, ##: Comments
target: Target stderr notice


Conditions:
a) PPI error Interrupts turned off:
Only PPI_STATUS is checked at the end of a frame read.

Error conditions are examined as well.

----------------------------------------------------------------------------
TEST 1: Provoke frame track overflow
----------------------------------------------------------------------------

Initializing video with 8x1
using DMA 13
Enabling PACK mode
oneshot(), took 25 ms
PPI_STATUS: 0014
0118:0001
1E 0D 1E 0D 1E 0D 1E 0D 00 00 00 00 00 00 00 00    ................

target:    Horizontal Tracking overflow error      # (NOT expected)
target:    Frame Track overflow                    # (expected)

## Data ok
## False Horizontal Tracking overflow

----------------------------------------------------------------------------
TEST 2: Try normal data acquisition
----------------------------------------------------------------------------

Initializing video with 8x2
using DMA 13
Enabling PACK mode
oneshot(), took 26 ms
PPI_STATUS: 0004
0118:0002
1E 0D 1E 0D 1E 0D 1E 0D 0B 1E 0B 1E 0B 1E 0B 1E    ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................

target:    Horizontal Tracking overflow error      # (NOT expected)

## Data ok
## False Horizontal Tracking overflow

----------------------------------------------------------------------------
TEST 3: Provoke Horizontal tracking overflow
----------------------------------------------------------------------------

Initializing video with 4x2
using DMA 13
Enabling PACK mode
Timeout.
PPI_STATUS: 0004
0118:0002
1E 0D 1E 0D 0B 1E 0B 1E 00 00 00 00 00 00 00 00    ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................

target:    Horizontal Tracking overflow error      # (expected)

## DMA times out, DONE irq not fired.
## Data ok, both rows are read

DMA channel status after PPI transaction:

-----------------  DMA13  ----------------------
STATUS:                0x0008  - [DMA Running]
START_ADDR             0x00000118
NEXT_DESC_PTR          0xdca0dfeb
CURR_DESC_PTR          0x1eff1a2e
X_COUNT                0x0001
Y_COUNT                0x0002
CURR_X_COUNT           0xffff           # <<< This is strange.
CURR_Y_COUNT           0x0002
PERIPHERAL_MAP         0x1000
CURR_ADDR              0x00000120
CONFIG                 0x009b  - [DMAEN] [WNR] [WDSIZE 32] [DMA2D] [DI_EN] [NDSIZE 0] [FLOW STOP]

## 2D DMA with a single 32 bit word transfer per line does NOT signal
## completion!

## Note: It works, when configuring the sensor WIDTH to 16 and
## X_COUNT to 2 and LINE to 8

----------------------------------------------------------------------------
TEST 4: Provoke underflow error
----------------------------------------------------------------------------

## Reading more data per line than fed by sensor:

Initializing video with 16x2
using DMA 13
Enabling PACK mode
oneshot(), took 26 ms
PPI_STATUS: 0004
0118:0002
1E 0D 1E 0D 1E 0D 1E 0D 00 00 00 00 00 00 00 00    ................
0B 1E 0B 1E 0B 1E 0B 1E 00 00 00 00 00 00 00 00    ................

target:    Horizontal Tracking overflow error      # (NOT expected)

## Data bad, but expected. Note begin of new line.
## For this case, an underflow error is expected

----------------------------------------------------------------------------
TEST 5: Reading more lines than fed by sensor:
----------------------------------------------------------------------------

Initializing video with 8x4
using DMA 13
Enabling PACK mode
Timeout.
PPI_STATUS: 0004
0118:0004
1E 0D 1E 0D 1E 0D 1E 0D 0B 1E 0B 1E 0B 1E 0B 1E    ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................

target:    Horizontal Tracking overflow error      # (NOT expected)

## Data ok, 0-padded as expected
## Frame Underflow error expected!!
## DMA times out which is expected (IRQ not called)

----------------------------------------------------------------------------
TEST 6: Provoke Horizontal underflow again
----------------------------------------------------------------------------

## Above the suspected 'threshold' value, we should see an underflow error.

Initializing video with 974x1
using DMA 13
Enabling PACK mode
oneshot(), took 26 ms
PPI_STATUS: 0014
0118:0001
1E 0D 1E 0D 1E 0D 1E 0D 00 00 00 00 00 00 00 00    ................

target:    Horizontal Tracking overflow error      # (NOT expected)
target:    Frame Track overflow                    # (expected)

## Increasing width:

Initializing video with 975x1
using DMA 13
Enabling PACK mode
oneshot(), took 26 ms
PPI_STATUS: 001c
0118:0001
1E 0D 1E 0D 1E 0D 1E 0D 00 00 00 00 00 00 00 00    ................

target:    Horizontal Tracking overflow error      # (Not expected)
target:    Horizontal Tracking underflow error     # (expected)
target:    Frame Track overflow                    # (expected)

## We should see a overflow error above value '9'!
## Examining the timing of the sensor, it turns out that a new
## rising edge of the FS1 signal is asserted 974 clock cycles after the previous
## rising edge.
## This suggests, that the underflow detection is behaving faulty.
## An underflow condition should occur when the FS1 duration (pulse width) is
## longer than `LINE` PPI-Clock cycles. Correct?