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
See fval8.png: yellow: FS2, blue: FS1
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?