How to configure VPCC for discrete 16bit YUV422 (DM8168 EVM)

I've just finished searching through the DM8168 TRM, but can't find anywhere that actually describes the settings/registers for the VIP. Searching around for information on the HDVICP2 which I believe contains the VIP hardware, I can't seem to find any documentation it.

Debugging with CCS I found that my "dummy" driver was too much of a dummy, and wasn't setting some output params on one of the FVID2_control calls.

Still could use some assistance on how best to get discrete input from the VFCC.

I've traced the configuration of the VIP to where the registers are actually configured in /opt/ezsdk/hdvpss_01_00_01_26/packages/ti/psp/vps/hal/src/vpshal_vip.c, in particular register PORT_A is getting set to 0xA014, of which it appears the SYNC_TYPE bits are set to 0x4 (the lower 4 bits of PORT_A according to the mask/shift defiend in /opt/ezsdk/hdvpss_01_00_01_26/packages/ti/psp/cslr/cslr_vps_vip_parser.h.

I know that my imager is currently generating HSYNC and VSYNC signals. Of which HSYNC should be passed properly to pin 95 on J17 of the EVM. While this is labeled TSI6_DATA in the schematic, I see no alternate names for ball AU5 on the Netra, so there should be no pin-mux issue for this input, correct?

Josh,

I have forwarded your driver questions to the relevant team members.  As for the pin AU5, you are correct that there are no other alternate functions for this pin; you just need to make sure that the pin mux register PINCTRL32 is set to enable that function (MUXMODE = 0x001.)

Regards,
Marc

Some further information: I've found and configured the settings for correct HSYNC and VSYNC polarity, and we are now driving ACTVID along with these signals.

So far in my efforts to get 16 bit images using discrete sync signals, I have: * Written a dummy video decoder driver which claims to detect a matching video feed with the following parameters: 1280x960@60Hz progressive. (This could later be merged with our imager setup code to become a real driver) * Converted large numbers of Log_print statements to simpler System_printf (which actually works) so that I can observe the normal debug messages from various components and drivers * Added additional debug output to observe operation of the various modules including the vpsdrv_captureVip driver, TVP component and VFCC component * Manually overridden the HSYNC, VSYNC and ACTVID polarity settings in the VIP parser setup to match our imager's output As for the hardware side of things: * Attempted to use both VIP0 and VIP1 (port A of each of course) * Introduced the required ACTVID signal via the CPLD (in lock-step with HSYNC) * Confirmed that our signals are clean and observable right up to the edge of the Netra processor * Successfully captured images from the TVP5158 (uses 8-bit YUV, 4x pixel-muxing and embedded syncs rather than discrete syncs) to prove that we can capture *some* kind of video using our card and my image pipeline works (VFCC->CMUX->basket.c:WriteVideoFrames()) My current configuration settings for the modified VC3 demo are:

#define IL_CLIENT_VIDEOCAPTURE_MODE          (OMX_VIDEO_CaptureModeSC_NON_MUX )
#define IL_CLIENT_VIDEOCAPTURE_VIFMODE       (OMX_VIDEO_CaptureVifMode_16BIT)
#define IL_CLIENT_VIDEOCAPTURE_INCOLORFORMAT ( OMX_COLOR_FormatYCbYCr)
#define IL_CLIENT_VIDEOCAPTURE_PORTS         (OMX_VIDEO_CaptureHWPortVIP2_PORTA)
#define IL_CLIENT_VIDEOCAPTURE_SCANTYPE      (OMX_VIDEO_CaptureScanTypeProgressive)
#define IL_CLIENT_VIDEOCAPTURE_MAXWIDTH      ( 1280 )
#define IL_CLIENT_VIDEOCAPTURE_MAXHEIGHT     ( 960 )
#define IL_CLIENT_VIDEOCAPTURE_STREAMS       ( 1 )
#define IL_CLIENT_VIDEOCAPTURE_MAXCHNLS      ( 1 )

and I have disabled all components not strictly required for our pipeline, which leaves only VFCC, CTRLTVP( with my dummy raw driver) and CMUX. All others are never created nor connected. As far as I've been able to debug in code-composer while stepping through the execution of the capture driver (hdvpss_01_00_01_26/packages/ti/psp/vps/drivers/capture/src/vpsdrv_captureApi.c:Vps_captDequeue():465), VpsUtils_queGet() finds that there are no frames to available to dequeue. I'm guessing this means that hardware is thus truly not recognizing any frames.

Whilst trying to get frames from the TVP5158, I must have accidentally set the wrong value for CaptureMode: Prior to adding the ACTVID signal I indeed had it properly set to SC_DISCRETESYNC, but I guess I had a brain fart and accidentally selected SC_NON_MUX.

Now that I'm collecting frames, I have some kind of buffer-limit issue, and my defined frame width/height is being ignored (I'm getting frames that claim to be 720x480, but are infact 1280x288. I'm confident I'll figure the rest out, but any tips or advice would be helpful.

--
Josh Watts

Update:  Looking for input on 'Poor Sync Timing' and 'possible shifted bits' - does this have to do with CPLD?

Posted by Marc D'Amato - per customer email...

I've gotten the last of the pipeline bugs resolved:

* Capturing full frames (no longer limited to 288 lines)

* Frame metadata is properly passed through pipeline (final component had hard-coded values for some reason...)

* Server/Client code is working reasonably well (can occasionally get into a resource conflict, but I'll iron that out when I have time)

* Server can set register values in camera

What isn't working:

* Frames show evidence of poor sync timing, and possibly shifted bits (CPLD code needs tweaking/improvments?)

* Poor frame-rate: 7fps (This could possibly be due to excessive debug output, which I will soon be removing, but I don't expect much more than maybe a frame or two more per second)

See attached for examples of "full" frames

I'm still investigating sync-timing, but I can at least say that I'm not getting shifted bits: Instead it appears that under certain circumstance the 4th bits (0x0008) is being overwritten by the capture port. As we are only dealing w/ 12bits of data, I'm using our CPLD to shift our 12bits into the upper portion of the 16-bit interfaces (0xFFF0) and then un-shifting when the frame reaches the A8 core. Interestingly however, I've shown that I can safely send the patterns 0xFFFF, 0x5555 and 0xAAAA without losing bits (IIRC, I will be double checking these values soon).

Poor frame-rate is entirely an side-effect of what I'm doing with the frames once they reach the A8 core from the CMUX component. If I drop all frames that reach that point, I'm actually something more than 45 FPS. For the time being, we're not yet concerned with this, and is entirely due to poorly written code on my part. ;-)

See the attached images for examples of sync issues (our imager is producing a 12-bit bayer), both of these images were capture with the same settings in the same test run, but were captured at different times.

hi Josh,

Here is what I recommend to isolate if this is capture driver/VIP port related issue or some application level issue.

In the HDVPSS driver we have a capture only example. Can you try that first up ?

The example can be found at HDVPSS_01_00_01_26\packages\ti\psp\examples\common\vps\capture\captureVip\src

You can do some top level configuration as below to make it work with 16-bit discrete sync capture

<1>

CaptureVip_main.h:Modify below line to configure how time you want the app to run.

/* Default run count in secs */
#define CAPTURE_APP_RUN_COUNT   (10)

<2>

CaptureVip_main.c

CaptureApp_UtParams is what we use to configure the test app for a given config.

If you see gCaptureApp_utParams<Xxxx>Ch[] we have multiple such config for TI EVM for TVP5158 and TVP7002

You want to use a config like below for your purpose

{
     FVID2_VPS_VID_DEC_TVP7002_DRV,
     1, VPS_CAPT_VIDEO_CAPTURE_MODE_SINGLE_CH_NON_MUX_DISCRETE_SYNC, 1,
     CAPTURE_APP_RUN_COUNT,
     VPS_CAPT_VIDEO_IF_MODE_16BIT, FVID2_DF_YUV422P,
     1, {FVID2_DF_YUV422I_YUYV, FVID2_DF_INVALID, FVID2_DF_INVALID}
     ,
     CAPTURE_SC_DISABLE_ALL, 0}

<3>

I dont know how you program your sensor, if you do it separatly, like from A8 side, then you should comment out the code related to TVP7002 setup.

Else add your code to setup the sensor in this file.

<4>

Run this app via CCS after execution completes it will output a whole bunch of statistics like frame rate, frame width/height of capture data and so.
I am interested in seeing what this log is. This usually give a clue as to whats going on, fps drop, sync problem etc.

Once this app reports clean status then I would recommend trying with other components.

regards

Kedar

I wish I had noticed the captureVip example much earlier! I was able to modify it to work with our imager quite easily, and also added my multi-frame checking code to CaptureApp_callback(). As part of this I added a little bit of my own information to the statistics that are collected:

[CortexM3_ISS_0] tsi6_data (0x087c) is being set to 1: vin0_hsync0
[CortexM3_ISS_0] === HDVPSS Clocks are enabled ===
[CortexM3_ISS_0] === HDVPSS is fully functional ===
[CortexM3_ISS_0] === HDVPSS module is not in standby ===
[CortexM3_ISS_0] === I2C1 Clk is active ===
[CortexM3_ISS_0]  CAPTUREAPP: HDVPSS Drivers Version String: HDVPSS_01_00_01_26
[CortexM3_ISS_0] *** VPDMA Firmware Loading... ***
[CortexM3_ISS_0] VPDMA Firmware already loaded !!!
[CortexM3_ISS_0] VPDMA Firmware Version = 0x4d000185
[CortexM3_ISS_0] VPDMA List Busy Status = 0x00000000
[CortexM3_ISS_0] *** VPDMA Firmware Load Success ***
[CortexM3_ISS_0] 
[CortexM3_ISS_0]  CAPTUREAPP : Detected [UNKNOWN] Board !!! 
[CortexM3_ISS_0]  CAPTUREAPP: CaptureApp_init() - DONE !!!
[CortexM3_ISS_0]  CAPTUREAPP: Loop 1 of 1 !!!
[CortexM3_ISS_0]  CAPTUREAPP: HANDLES 1: MODE 0003 : CH 1: RUN COUNT 10: OUTPUT:1:12292 !!!
[CortexM3_ISS_0] Port enabled: 178
[CortexM3_ISS_0] Setting PORT_A to a014, portConfig->syncType = 4
[CortexM3_ISS_0]  CAPTUREAPP: 0: CaptureApp_create() - DONE !!!
[CortexM3_ISS_0] FVID_CONTROL: IOCTL_VPS_VIDEO_DECODER_GET_CHIP_ID
[CortexM3_ISS_0]  CAPTUREAPP: VIP 0: VID DEC 0403 (0x00): 0000:0000:0000
[CortexM3_ISS_0]  CAPTUREAPP: Detect video in progress for inst 0 !!!
[CortexM3_ISS_0] FVID_CONTROL: IOCTL_VPS_VIDEO_DECODER_SET_VIDEO_MODE
[CortexM3_ISS_0] FVID_CONTROL: IOCTL_VPS_VIDEO_DECODER_GET_VIDEO_STATUS
[CortexM3_ISS_0]  CAPTUREAPP: Detected video at CH0 (1280x960@60Hz, 0)!!!
[CortexM3_ISS_0]  CAPTUREAPP: Detect video Done !!!
[CortexM3_ISS_0]  CAPTUREAPP: Starting capture ... !!!
[CortexM3_ISS_0] FVID_CONTROL: FVID2_START
[CortexM3_ISS_0]  CAPTUREAPP: Starting capture ... DONE !!!
[CortexM3_ISS_0]  CAPTUREAPP: Capture in progress ... DO NOT HALT !!!
[CortexM3_ISS_0] CAPTURE FVID2_START
[CortexM3_ISS_0] Port enabled: 178
[CortexM3_ISS_0] CAPTURE FVID2_STOP
[CortexM3_ISS_0] Port enabled: 178
[CortexM3_ISS_0]  CAPTUREAPP: Stopping capture ... !!!
[CortexM3_ISS_0] FVID_CONTROL: FVID2_STOP
[CortexM3_ISS_0]  CAPTUREAPP: Stopping capture ... DONE !!!
[CortexM3_ISS_0]  
[CortexM3_ISS_0]  Execution Statistics 
[CortexM3_ISS_0]  ==================== 
[CortexM3_ISS_0]  
[CortexM3_ISS_0]  Execution time    : 11.98 s 
[CortexM3_ISS_0]  Total field Count : 508 (45 fields/sec) 
[CortexM3_ISS_0]  Avg CPU Load      : 92  
[CortexM3_ISS_0]  Broken frames     : 4 
[CortexM3_ISS_0]  Broken stats      :
[CortexM3_ISS_0]  0: 56
[CortexM3_ISS_0]  1: 56
[CortexM3_ISS_0]  2: 56
[CortexM3_ISS_0]  3: 56
[CortexM3_ISS_0]  
[CortexM3_ISS_0]  *** Capture Driver Advanced Statistics *** 
[CortexM3_ISS_0]  
[CortexM3_ISS_0]  VIP Parser Reset Count : 0
[CortexM3_ISS_0]  
[CortexM3_ISS_0]      |   Total    Even     Odd  Total  Even   Odd  Min /  Max  Min /  Max Dropped FrmErr
[CortexM3_ISS_0]  CH  |  Fields  Fields  Fields    FPS   FPS   FPS       Width      Height  Fields (DescErr)
[CortexM3_ISS_0]  ------------------------------------------------------------------------------------------
[CortexM3_ISS_0]  000 |     508     511       0     45    46     0 1280 / 1280  964 /  964       0      0(0)
[CortexM3_ISS_0]  
[CortexM3_ISS_0]  *** Capture List Manager Advanced Statistics *** 
[CortexM3_ISS_0]  
[CortexM3_ISS_0]  List Post Count        : 644 
[CortexM3_ISS_0]  List Stall Count       : 0 
[CortexM3_ISS_0]  List Post Time (ms)    : Max = 1, Min = 0, Avg = 0, Total = 28 
[CortexM3_ISS_0]  Error descriptor count : 0 
[CortexM3_ISS_0]  Recv  descriptor count : 0 
[CortexM3_ISS_0]  Extra descriptor programmed count : 0 
[CortexM3_ISS_0]  
[CortexM3_ISS_0]  
[CortexM3_ISS_0]  VIP and VPDMA registers, 
[CortexM3_ISS_0]  VIP0 : FIQ_STATUS  : 0x4810551c = 0x00000400
[CortexM3_ISS_0]  VIP1 : FIQ_STATUS  : 0x48105a1c = 0x00000000
[CortexM3_ISS_0]  VPDMA: LIST_BUSY   : 0x4810d00c = 0x00000000
[CortexM3_ISS_0]  VPDMA: PERF_MON34 = 0x4305ffff, PERF_MON35 = 0x4305ffff, PERF_MON38 = 0x4305ffff, PERF_MON39 = 0x4305ffff 
[CortexM3_ISS_0]  
[CortexM3_ISS_0]  
[CortexM3_ISS_0] Port enabled: 178
[CortexM3_ISS_0]  CAPTUREAPP: 0: CaptureApp_delete() - DONE !!!
[CortexM3_ISS_0]  CAPTUREAPP: ERROR COUNT 0: HANDLES 1: MODE 0003 : CH 1: RUN COUNT 10: !!! - DONE
[CortexM3_ISS_0] 
[CortexM3_ISS_0]  11553: LOAD: CPU: 89 HWI: 0, SWI:0 
[CortexM3_ISS_0] 
[CortexM3_ISS_0]  CAPTUREAPP: CaptureApp_deInit() - DONE !!!

As you can see, we are currently getting about 45 FPS (apparently unaffected by my bit-shifting and multi-frame-check code). I haven't looked terribly close at how the frame's buffer is supposed to be accessed, but I found (empirically) that when viewed a an array of uint16 values, every other value is 0x0000 except in the first four frames where there is some kind of garbage data in the odd pixels.

It seems from this test that things are fine inside the capture component (unless something from above looks odd to you?), so it must be something wrong with the code after the VPSS passes the data along.

EDIT: This is the code I added to CaptureApp_callback:

                        gCaptureApp_ctrl.totalFieldCount += frameList.numFrames;

#define MULTI_FRAME_CHECK
#define FRAME_SHIFT

#ifdef MULTI_FRAME_CHECK
                        int i = 0;
                        for (i = 0; i < frameList.numFrames; i++) {
                                int x;
                                uint16_t *buf = (uint16_t*)(frameList.frames[i]->addr[0][0]);
                                uint16_t *bp = buf;
                                volatile uint16_t t = 0;
                                uint16_t image_height = 0, image_width = 0, last = 0;
                                Vps_CaptRtParams *pCaptInfo = frameList.frames[i]->perFrameCfg;                   
                                uint16_t image_size = pCaptInfo->captureOutHeight * pCaptInfo->captureOutWidth;
                                for (x = 0; x < image_size; x++) {
#ifdef FRAME_SHIFT /* CPLD is shifting bits from 11:0 to 15:4, plus we would like our bits in network byte order */
                                        t = (*bp & 0xF000)>>12 | (*bp & 0xFF)<<4;
                                        *bp = t;
#endif                                 
                                        if (*bp != 0x0000 && *bp != 0x0808 && *bp != 0x8000 && *bp != 0x0080) {
                                                /* Ignore nulls (every other pixel?) */
                                                //printf(" **BAD FRAME** ");
                                                //break;
                                                if (bp == buf) {
                                                        last = *bp;
                                                        //printf("%04x", *bp);
                                                        image_width++;
                                                } else if (*bp != last) {
                                                        image_height++;
                                                        //printf("(%d) -> %04x", image_width, *bp);
                                                        image_width = 0;
                                                        last = *bp;
                                                }
                                        }
                                        bp++;
                                }
                                //printf("(%d)\n", image_width);
                                if (image_height > 1) {
                                        //printf("%d different pixels detected in frame %8d\n", image_height, frameNumber[i]);
                                        gCaptureApp_ctrl.totalBrokenFrames++;
                                        gCaptureApp_ctrl.brokenFrameInfo[frameNumber++] = image_height;
                                }
                        }
#endif


                        /*
                         * Queue back the frames to the driver
                         */
                        FVID2_queue ( gCaptureApp_ctrl.fvidHandleVipAll, &frameList,
                                        streamId );

hi Josh,

I think the VIP port is truely getting data at 45fps, so maybe there is something going on outside the VIP port.

Still can you send me the below register setting dump

0x48105500 to 0x48105520
0x4810010C

This will tell me if the VIP settings as programmed by the driver are fine or not.

Also can you send me data dump of one frame of data the you capture.
The data dump should be the raw data that the capture driver capture before any bit shifting by SW.

regards
Kedar

Am trying to figure out a way to dump a frame using CCS. Until I figure that part out, here's the registers you inquired about (paused CPU about half a second in to the test-run):

0x48105500 00000001 0000A114 00000000 00000000 00000000 00000000 00000000 00000400
0x48105520 FFFFFFFC FFFFFFFC FFFFFFFF FFFFFFFF 050003C4 00000000 00000000 00000000
...
0x4810010C 40008000 40000000 000C010E 00000000 00000000 00000000 00000000 00000000

I created a break-point shortly before where my code does the bit-shifting and using the memory browser saved it to a hex file. Uncompressed it is 20 MiB, see attached zip file: 4214.netra_debug_pattern_capture.zip

Looking through the hex file I generated, as well as in the memory browser, there are chunks (equally sized?) which are not data from our imager/cpld. Each frame should consist of a single 16bit value repeated back-to-back. The value itself is incremented after the end of each frame (but before the next). Alternating rows in memory and the hex file are some variation of 0x8080, 0x8000 or 0x0080. I'm currently working on analyzing the binary data file I've just generated to see how many rows I really am getting from my imager and how many are "junk". See attached file (7.1 MiB): 1122.netra_raw_image_capture.zip

At this point, I'm confident that the multi-frame issue must be somewhere in my code, but I'm still concerned about the pattern that's showing up on every other line. Specifically, if it's coming from the VIP, could that same pattern be overlaid in my imager's output? (Again, I'm interested in capturing 12 unmodified/altered raw bits per pixel in whatever way I can)

That actually took less time than I expected. In netra_raw_image_capture.bin:

Value 4005 appeared on 964 lines
Value 5005 appeared on 840 lines
Value 8080 appeared on 1803 lines

It would appear that I mis-calculated the amount of memory to download, but I can also clearly see that every other row is the value 0x8080. I'm going to see if I can reproduce this is our modified VC3 demo and adjust for it.

(I think my analysis program was incorrectly double-counting rows in my previous post, 964 should be 482 I believe)

I set a breakpoint in omx_vfcc_drvif.c just before Step 4b in _OMX_VFCCDrvIfProcessFcn() and got the frame address of 0xB2E00080. I then ran the following in the scripting console:

saveRaw(0, 0xB2E00080, "asdf2.bin", 0x96000, 32, true);

In the resulting binary file (5100.netra_raw_image_capture_vfcc.zip) I see a perfect set of two half-frames (1280x480 of value 0xC07F, and 1280x480 of value 0xD07F). I have not added any code to modify the contents of the frame buffer, either before or after this point in the code. The number 480 is quite suspicious to me... and though I'm reasonably certain that I have correctly defined MAX_RESOLUTION_HD, so that OMX_VFCC_DEFAULT_OUTPUT_FRAME_HEIGHT is set to 1080 (otherwise it would be 480). Any thoughts on where I should look to verify that the min height is being set properly?

Right from one issue into another: The only thing I've changed is the previously stated OMX_VFCC_DEFAULT_OUTPUT_FRAME_HEIGHT and OMX_VFCC_MAX_OUTPUT_FRAME_HEIGHT values. Before this, the VIP was returning frames with metadata claiming to contain my requested 1280x960 frame, albeit with half it's data overwritten. Now, however, I'm getting frames of 1280x288. I'm trying to track the source of this, but any thoughts on where to look would be highly appreciated.

Josh

can you check the contents of RT params at the following location in

pCaptureRtParams = ( Vps_CaptRtParams * ) pFrame->perFrameCfg;  @ step 4a.

Are the contents are as expected? The same info. used to send the buffer to the next component in the following function

_OMX_VFCCSetOmxBufHdrInfo:

  /* Frame Width */
  sOutBufHeaderPtr->nFrameWidth = pCaptureRtParams->captureOutWidth;
  /* Frame Height */
  sOutBufHeaderPtr->nFrameHeight = pCaptureRtParams->captureOutHeight;

regards,

Tarakesh.

Got it: in omx_05_00_00_11/packages/ti/omx/comp/vfcc/src/omx_vfcc_drvif.c, in two places, there's a check if boardId equals VPS_PLATFORM_BOARD_VC, which it doesn't for our custom board. The result is that pOutInfo->maxOutHeight is assigned VPS_CAPT_MAX_OUT_HEIGHT_288_LINES. A quick #ifdef to force it to VPS_CAPT_MAX_OUT_HEIGHT_1080_LINES produces the correct results. Not sure why this changed so suddenly, possibly due to memory corruption.

I'm still getting an issue with the image being shifted left by ~30 pixels, but I haven't yet finished ruling out a bug in my code yet.

The last bug (shifted image) is indeed in my network code (skipped a structure when building up or breaking down the packet). Thanks again for all your help. :-)

Hi Marc,

I realized that we need to create one of these 'dummy' drives for our FPGA solution.

What is the quickest way to get the source code for this? NDA is already in place.

Best,

Andreas

I believe the (now somewhat out-dated) SDK I was working with was at one point available on the TI website. As I understand it, with the more recent SDK releases only the binaries for the co-processors are included in the SDK? To get access to their source, I think you will need to ask for it directly from TI.

You should email your TI representative directly, rather than submitting a new post on an old forum thread.

Hi Josh,

sorry for the repost but Marc is really the master of getting things done.I've contacted the local TI FAE without much luck.

I'm basically running a very similar video capture application as you do.

-Andreas

Hi Andreas,

Can you provide a few more details about exactly what you are looking for?  Can you ask your local TI Rep to contact me directly and we will get it worked out.

Regards,
Marc