diff options
| -rw-r--r-- | wiki/GMSL_Cameras_Open_Issues/vsync-csi-output.png | bin | 0 -> 125700 bytes | |||
| -rw-r--r-- | wiki/GMSL_Cameras_Open_Issues_and_testing.wiki | 136 | ||||
| -rw-r--r-- | wiki/css | 5 |
3 files changed, 141 insertions, 0 deletions
diff --git a/wiki/GMSL_Cameras_Open_Issues/vsync-csi-output.png b/wiki/GMSL_Cameras_Open_Issues/vsync-csi-output.png Binary files differnew file mode 100644 index 0000000..bc17abf --- /dev/null +++ b/wiki/GMSL_Cameras_Open_Issues/vsync-csi-output.png diff --git a/wiki/GMSL_Cameras_Open_Issues_and_testing.wiki b/wiki/GMSL_Cameras_Open_Issues_and_testing.wiki new file mode 100644 index 0000000..d884072 --- /dev/null +++ b/wiki/GMSL_Cameras_Open_Issues_and_testing.wiki @@ -0,0 +1,136 @@ +h1. GMSL Cameras Open Issues and testing + +h2. Frame synchronization isn't fully understood + +The MAX9286 deserializer requires input frames to be synchronized. Cameras does operate in external trigger mode, where a frame sync signal broadcasted by the MAX9286 over all enabled GMSL links is output by the MAX9271 serializers on their GPO pin to the camera sensor. The MAX9286 can be configured to generate the frame sync signal internally, or based on an external sync signal received on its GPI pin. The current code uses internal sync unconditionally. Previous experiments used external sync when enabling a single camera. As the SoC GPIO connected to the MAX9286 GPI pin is never toggled this shouldn't have worked, but for an unknown reason we could still capture valid frames. This has to be investigated and understood. + +Understand how frame sync is emitted and which conditions prevent it from locking. + +h3. Test + +1) +Use manual frame sync with a frame period of 1905x840 pixels ( = 1905x840x2 PCLK pulses in YUYV8 format) +No locking, but monitoring calculated master link VSYNC period returns the exact number of expected PCLK pulses + +<pre> + master vsync period - 0x30d590 = 3200400 = 1905*840*2 +</pre> + +This at least confirms that FSYNC is successfully fed to camera sensors + +2) +Play around with KVAL, PVAL and DIFF periods +Anticipating that the manual does not provide any information on what time constraints have to be respected to have a successful KVAL + PVAL hit (Figure 46, above reported), play around with configuration parameters. +DIFF can be disabled (to confirm what does it mean) + +*patch* +http://jmondi.org/owncloud/index.php/s/RG0rq870YEHOtAy + +3) +Change AUTO_MODE to SEMI_AUTO_MODE +Try to have VSYNC follow the master link, not slowest one + +4) Try to use i2c broadcast address +To start all cameras at the same time + +*patch* +http://jmondi.org/owncloud/index.php/s/Fj56fNUWsFPlhBi + +h2. Horizontal and vertical sync configuration + +The MAX9286 is configured to invert vertical sync, while the MAX9271 isn't. Check whether this is caused by the sensor using a vertical sync polarity opposite of what the MAX9286 expects. Furthermore, sync signals can be encoded in different GMSL bits, make sure the serializer and deserializer agree. + +Possible answer: the INVSYNC option on de-serializer side, is used to invert vsync signal on CSI output (pag. 14 of MAX9286 programming guide) + +<pre> + INVVS Invert Vsync in CSI output +</pre> + +1) Theory 1: +De-serialize outputs <fs> on VSYNC rising edge, <fe> on VSYCN falling edge. +This would result in an invalid <fs><fe><fs> sequence on CSI-2 bus and that would explain why vertical synchronism are inverted on CSI-2 bus output. + +Figure 32 in de-serialize manual is below reported +!GMSL_Cameras_Open_Issues/vsync-csi-output.png! + +and seems to contradict the hypothesis since a single short packet is emitted on VSYNC falling edge + +<pre> +Hypothesis 1: CSI short packets for frame start/end are inverted + _ _ _ +VSYNC ________| |________________________________| |_______... ______| |_______________ + ____ ____ ____ +HREF ___________| |__| |__ ... __| |__ ... +GMSL DATA <VS1><VS0><HS1><pixel data> ... <pixel data><HS0><HS1><pixel data> ... <pixel data><HS0><VS1><VS0> +CSI <fs> <fe> <ls-0> <pixel data> ... <pixel data> <le-0> ... <ls-n> <pixel data> ... <pixel data> <le-n> <fs> <fe> +INVSYCN +CSI <fe> <fs> <ls-0> <pixel data> ... <pixel data> <le-0> ... <ls-n> <pixel data> ... <pixel data> <le-n> <fe> <fs> +</pre> + +2) Theory 2 +The OV10635 sensor is sending inverted VSYNC. +Try to change this setting bit 2 of register 0x4708 + +h3. Testing + +The deserializer is configured to invert VSYNC. Frame capture from one camera, with this configuration works fine. + +1. Remove VSYNC inversion in max9286 -> green frames +2. Invert VSYNC polarity on OV10635 side ( 0x4708 = 0x02 ) and remove VSYNC inversion on max9286 -> good frames + +This seems to confirm, OV10635 is configured to use active low VSYNC signal polarity + +h2. Lock and synchronization monitoring + +The MAX9286 provides status registers to monitor locking and synchronization. We need to make use of them for instrumentation purpose, in order to better understand the MAX9286 operation and detect error conditions. This includes the control link, serial link and video synchronization. + +Register used to monitor MAX9286 operations + +|_. Register Name |_. Register Address |_. Bits |_. Comment| +| Video Links Detected | 0x49 | D3:D0 | | +| Links Locked | 0x27 | D7 | All video links are locked | +| VSYNC Detected | 0x27 | D3:D0 | VSYNC detected on link 3:0 in the last 100ms (0ed when read) | +| Frame Diff | 0x31 0x30 | D5:D0 - D7:D0 | Difference in master PCLK cycles between fastest and slowest link | +| Master Link | 0x71 | D5:D4 | ID of link selected as master | +| FSYNC Error Counter | 0x5e | D7:D0 | Frame sync error counter (reset to zero when read)| +| Master VSYNC period | 0x5d 0x5c 0x5b | D7:D0 | Calculated VSYNC period of master link in PCLK cycles | +| FSYNC Locked | 0x31 | D6 | Frame sync locked | + +*Testing* + +Printout of values while waiting for FSYNC locking. +Configuration: +# Link 0 and 1 enabled +# AUTO FSYNC mode +# + +<pre> +[ 48.760818] vsync detected 0x27[3:0] = b3 +[ 48.764843] fsync locked 0x31[6] = 00 +[ 48.768515] framediff 0x31[5:0] 0x30 = 3f fe +[ 48.772791] master link 0x71[5:4] = 00 +[ 48.776547] fsync err 0x52[7:0]= 01 +[ 48.780042] master vsync per - 2d 07 50 +[ 48.783884] <-------- usleep_range(2000, 50000); +[ 48.841958] vsync detected 0x27[3:0] = b3 +[ 48.845974] fsync locked 0x31[6] = 00 +[ 48.849634] framediff 0x31[5:0] 0x30 = 3f fe +[ 48.853916] master link 0x71[5:4] = 00 +[ 48.857672] fsync err 0x52[7:0]= 06 +[ 48.861158] master vsync per - 2d 07 50 +</pre> + +*Patch* +http://jmondi.org/owncloud/index.php/s/OLz8Ah7ZZH6X1t0 + +h2. Frame combination isn't fully understood + +According to page 26 of the MAX9286 datasheet, the deserializes combines all input video streams into a single (4 x W) x H or W x (4 x H) frame. How to select which combination mode to use isn't specified in the datasheet, neither is it explained how CSI-2 virtual channels are used. Previous experiments to capture a (4 x W) x H frame failed, with the VIN never signalling frame completion. More experiments are needed to understand how frame combination operates. + +h2. Errors in the MAX9271 datasheet + +The MAX9271 datasheet contradicts some of the tests we have performed, which could indicate errors in the datasheet. + +* Register 0x15 - PCLKDET + + The bit seems to be inverted, we read PCLKDET = 1 when a pixel clock is present. @@ -6,3 +6,8 @@ table { table th, table td { border: solid 1px gray; } + +pre { + background-color: #e5ffe5; + border: solid 1px gray; +}
\ No newline at end of file |
