This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM5726: VIP: One extra line of data is added at the end

Part Number: AM5726

Hi

Our customer are facing trouble to transfer the RAW8 format image data via VIP into memory.

The image size is 1280x960. (Customer confirmed at the waveform that the number of coming HSYNC signal is really 960.)

However, 1280x961 data are transferred into memory.

- This behavior doesn't depend on VIP1/2/2 and PortA/B. The issue is happened with any VIP port.

- About stored data in memory, upper 1280x960 are expected image data, but one extra line of data is added at the end.

  Therefore, total image size which are stored in memory is not 1280x960 but 1280x961.

- The contents of one extra line of data is sometimes all 0, and is sometimes the image data of last line.

- It's happened with RAW8 or YUV422 format, but no happened with RAW16 format

Is above one expected behavior? (and reason why?)

If it's not expected one then could you please support to solve it?

Thanks and Best regards,
HaTa.

 

 

  • Hi Ha Ta,

    What is the resolution of the buffer application is creating?

    Is the observation with the output from VIP directly? or is there any color conversion/scaling involved?

    Please let me know which SDK version is used here.

    Thanks & Regards,

    Sunita.

  • In addition, what is the input interface, HS & VS or DE & VS?

    Rgds,

    Brijesh

  • Hi Ha Ta,

    In addition, few more points to check

    1. PORTA_SIZE register which will reflect the frame size as detected by parser.

    2. hsync polarity 

    Thanks & Regards,

    Sunita.

  • Hi Sunita

    Customer need to know your status for this issue within today.

    Please answer the following 2 questions ASAP.

    1: Do you already have any idea in your mind to solve the issue?

    2: How long do you estimate that this issue will be resolved within?

    The following are the answers for your questions. 

    What is the resolution of the buffer application is creating?

    ⇒ 1280 x 960

     

    Is the observation with the output from VIP directly? or is there any color conversion/scaling involved?

    ⇒ Any color conversion/scaling is not involved

     

    Please let me know which SDK version is used here.

    ⇒ SDK : ti-processor-sdk-rtos-am57xx-evm-04.02.00.09-Windows-x86-Install.exe

    PDK : v1.0.9

     

    What is input interface, HS & VS or DE & VS?

    ⇒ HS & VS

     

    And, few more points to check

    1. PORTA_SIZE register which will reflect the frame size as detected by parser.

    ⇒ 0x 05 00 03 C0   (1280, 960)

     

    2. hsync polarity

    ⇒ 1 ( Active High)

    Thanks and Best regards,

    HaTa.

  • Hi HaTa,

    VIP is reporting 1280x960 frame size and buffer is also allocated for 1280x960 frame size, so how are you seeing extra line? 

    Do you see more than 960 lines written in the memory? 

    Also does the input include any vertical blanking? 

    Regards,

    Brijesh

  • Hi Brijesh

    >Do you see more than 960 lines written in the memory? 

    Yes, therefore, as a result, the memory area reserved for others will be destroyed.

    The extra line is sometimes ALL0 and also sometime  

    Sometimes it is all 0 values, and sometimes it has the same data as the last row.

    >Also does the input include any vertical blanking? 

    I'll confirm.

    Could you please reply for

    1: Do you already have any idea in your mind to solve the issue?

    2: How long do you estimate that this issue will be resolved within?

    Thanks and Best regards,

    HaTa.

  • >Also does the input include any vertical blanking? 

    There are blanking period during vertical is in inactive state.

    There is no any data at this period.

    There is no any reason, but customer are suspicious to PDMA for this issue.

    Thanks and Best regards,

    HaTa.

  • Hi HaTa,

    I really doubt this is coming from DMA engine.

    Since you are using HS & VS signals, vertical front porch and back porch area, which is not part of the active vsync area, will also be captured by VIP. This should be cropped/trimmed off by using VIP trimmer.  We could even limit the DMA write in the descriptor.. 

    But for that, we need to know exact vertical frame timing. Then we can use one of the above mechanism to limit frame size to 960 lines. 

    Which drivers are you using for VIP?

    Regards,

    Brijesh

  • Hi Brijesh

    What do you mean of "Which driver"?

    They are using 

       SDK : ti-processor-sdk-rtos-am57xx-evm-04.02.00.09-Windows-x86-Install.exe

       PDK : v1.0.9

    Thanks and Best regards,

    HaTa.

  • Hi HaTa,

    I mean you are using PDK driver or Linux driver.

    Regards,

    Brijesh

  • Hi

    As I commented before, they uses RTOS. Therefore, I believe they uses PDK driver.

  • Hi HaTa,

    ok, What is the input video frame size including blanking? Can you please share video timing for the input video?

    Rgds,

    Brijesh

  • We use the VIP port to capture a single frame image, not a video frame.

    VIP is started and stopped every single capture.

    Therefore, we cannot define “the video frame size including blanking”.

  • In addition to,

    About Blue "//" period, Vsyn and Hsyn changes its status at the same time. Therefore, the period of "//" is 0 cycle.

    About Red "//" period,  there is about 260k~130M cycle between each single capture.

    Thanks and Best regards,

    HaTa.

  • Hi HaTa,

    If you are H input as HSYNC input and configured HS and VS input as active low input in VIP, then when vsync is high, the entire line from one rising edge of hsync to next rising edge will get captured in the memory. If there are more than 960 HS pulse when VS is high, then all of them will be captured by VIP.. 

    So please make sure that there are exactly 960 pulse of HS during this time. 

    Regards,

    Brijesh

  • Hi Brijesh

    Yes, customer confirmed that the number of HS is exact 960.

  • Hi HaTa,

    If there are exactly 960 HS pulses, when VSYNC is active, VIP will capture exactly 960 lines in the memory. Also VIP size register confirms that there are 960 lines.

    There is one more way to confirm if the number of lines received are 960 or not. In PDK driver, we can provide RT params in each fvid2_frame, driver will return the captured frame size for each frame. Can you add it and see if it reports any time more than 960 lines?

    Regards,

    Brijesh

  • Hi Brijesh

    I confirmed the following value after setting Vps_CaptRtParams to Fvid2_Frame.perFrameCfg and the transfer are completed,

    CaptRtParams .capturedOutWidth = 1280

    CaptRtParams .capturedOutHeight = 960

    Therefore, the input Height could be 960, but transferred Height is 961.

     

    Which VPDMA register are related to the number of Height?

    Thanks and Best regards,

    HaTa.

  • Hi HaTa,

    If the rt params reports the size as 1280x960, the DMA engine is not writing beyond 960 lines, at-least for this frame.

    Could you please check RT params for multiple frames? Please provide a separate instance of RT Param structure for each Fvi2_frame to return size for multiple frames.

    If you are using 3 Fvid2_Frames, then allocate 3 instance of RT Params and then pass it to fvid2_frame. When you dequeue the frame, please check the value of RT Params for multiple frames. 

    Regards,

    Brijesh

  • Hi

    We use only 1 Fvid2_Frame for single capture.

    In every capture, the RT param reports the size as 1280x960 and the buffer is written for 961 lines.

     

  • Hi HaTa,

    If the RT params report 960 lines, then very unlikely that DMA would write more than 960 lines. How do you know that it is more than 960 lines? 

    Before submitting frame to the VIP, can you write a known pattern at 961 line and then after capture, can you see if the pattern is overwritten or not?

    Regards,

    Brijesh

  • Hi Brijesh

    They start the investigation about the issue because data corruption was happened.

    They prepare the memory buffer with the size of 1280x960.

    Data corruption is happened in memory area for other.

     

    The contents of it is sometimes all 0, and is sometimes the image data of last line.

    This behavior doesn't depend on VIP1/2/2 and PortA/B. The issue is happened with any VIP port.

    It's happened with RAW8 or YUV422 format, but no happened with RAW16 format

  • Hi HaTa,

    Couple questions

    1, When it writes beyond 960 lines, do you see RT params reporting more than 960 lines? 

    2, it seems that the buffer is filled with 0x00 or 0xFF, is this value being transmitted by sensor? 

    Can you also try limiting the frame size written to the memory by using Vps_VpdmaMaxSizeParams interface? This structure needs to be passed with IOCTL_VPS_CAPT_SET_VIP_MAX_SIZE ioctl. This contains maxWidth and maxHeight parameter for each instance. In you case, set the maxWidth/maxHeight to VPS_VPDMA_MAX_OUT_WIDTH_REG1 and then set the max size in Reg1 to 1280x960. 

    Regards,

    Brijesh

    Regards,

    Brijesh

  • >1:When it writes beyond 960 lines, do you see RT params reporting more than 960 lines?

     

    No, the buffer is written beyond 960 lines every capture,

    and RtParams report 1280 x 960 everytime.

     

    >2: it seems that the buffer is filled with 0x00 or 0xFF, is this value being transmitted by sensor? 

    It's not the data from sensor.

    However, and is sometimes it' s the image data of last line.

    >Can you also try limiting the frame size written to the memory by using Vps_VpdmaMaxSizeParams interface?

    This structure needs to be passed with IOCTL_VPS_CAPT_SET_VIP_MAX_SIZE ioctl.

    This contains maxWidth and maxHeight parameter for each instance.

    In you case, set the maxWidth/maxHeight to VPS_VPDMA_MAX_OUT_WIDTH_REG1 and then set the max size in Reg1 to 1280x960.

     

    I tried to limit the frame size as you said, but nothing changed.

    (vipPrms->outStreamInfo : Vps_CaptVipOutInfo)

  • Hi

    Do you have any update?

  • Hi

    Do you have any update?

  • Hi HaTa,

    Once you set the 1280x960 as the limit in the DMA, there is no way that it would write beyond 960 lines. It is not possible. This is something else. Is there possibility that this buffer is being used by someone else in the system, before capture finishes? 

    Can you just use standalone capture module, without any other component and see if the last line is getting written? 

     

    Regards,

    Brijesh

  • Hi HaTa,

    Any further update on this issue?

    Let us know if it is resolved and issue can be closed.

    Regards,

    Brijesh

  • Hi Brijesh

    I'm confirming to customer about it.

    By the way, as customer's verification, the behavior is depend of the Image format.

    According to the specifications,  as you mentioned, such behavior is impossible, but is there a possibility that it is a bug?

    Could you try a similar simple test with a different image format?

    Thanks and Best regards,

    HaTa.

  • Hi HaTa,

    It is very unlikely that this behavior is format dependent. DMA does not know about format, it limits the size based on this configuration.

    Could you please get more information about which format it works, and for which format it does not work?

    Regards,

    Brijesh

  • Hi Brijesh

    All the information is in my first comment, therefore please refer it carefully, but the issue is happened with RAW8 or YUV422 and not with RAW16.

    RAW8/YUV422 and RAW16 could be pass through the different path in VIP.

    I 'm afraid if this causes the reason of this behavior.

    Thanks and Best regards,

    HaTa.

  • Hi HaTa,

    ok, what's the input interface for the RAW8 and YUV422 data? It is important to understand what is pixel for VIP in these cases. 

    Since it is working fine for RAW16 bit, i feel this is some minor config issue.

    Regards,

    Brijesh

  • Hi Brijesh

    What information do you need?

    They tested with VIP1/2/2 and PortA/B, and the issue is happened with any VIP port.

    The data camming in is

    The data is one-shot.

    Therefore, there are a lot of blanking period between each Vsync.

    Thanks and Best regards,

    HaTa

  • Hi HaTa,

    I mean what is the interface size between working and non-working case? Is it 8bit ie 8 data lines in both the cases? or it is different? 

    Regards,

    Brijesh