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.

TDA4VM: TDA4VM: Single camera application demo waiting infinitely in vxGraphParameterDequeueDoneRef function

Part Number: TDA4VM

Hi,

I am running single camera application after adding a new sensor driver (ISX016). I have done the following changes in the QNX+RTOS setup (07_03_00).

Serialiser : DS90UB913

Deserialiser : DS90UB964

1. Added a sensor driver folder (isx016) by referring "imx390".

2. Added Serialiser and deserialiser configurations in "isx016_serdes_config.h".

After adding the changes as mentioned in sensor_bringup_notes ,the newly added sensor is listed while running the application. But I was not able to get the image in the display. Seems like the "vxGraphParameterDequeueDoneRef" function waits for getting the data. Where I can look on to resolve this issue?

Regards,

Alex

  • Hi Alex,

    Are you checking this on the EVM? Which deserialiser board is connected to EVM? Is the deserializer board brought up to make sure it is working fine? 

    Other than above changes, please make sure that

    - number of lanes and lane position are matching as per the board schematic.

    - lane output speed is set to 1.5/1.6Gbps. This is what is by default used in the single camera example.

    - start the sensor and de-serializer output only in streamon callback.

    Can you please try with above changes?

    Regards,

    Brijesh 

  • Hi Brijesh,

    Sensor : ISX016

    Serialiser : DS90UB913

    Deserialiser : DS90UB964

    I have made the changes suggested by you.

    1. Confirmed the number of data lanes as 4.

    2. Lane output speed is set as 1.5/1.6 Gbps

    3. (0x33) register is loaded with value (0x03) only at the time of streamon callback.

    Still the issue is not resolved.

    I tried to read the values from deserialiser and serialiser and I was able to communicate properly.

    But when I try to read some values from the sensor (read using the sensor alias id), it is getting failed.

    Is there any method to confirm that the sensor communication is happening correctly?

  • Hi Alex,

    If you are not able to communicate with the sensor, can you check if there are any status registers in the serializer or deserializer that can provide sensor stream status like size of the fame or frame counter..

    Does sensor require any configuration? In this case, how do you make sure that it is configured correctly? 

    Regards,

    Brijesh

  • Hi Brijesh,

    I have checked the 0x1D (MAX_FRM_HI ) and 0x1E (MAX_FRM_LO) registers of UB964. Both registers don't have any change. Value is default only.

    Regarding sensor configuration, I haven't done any configuration from my side. I have only added the deserialiser and serialiser configurations. Rest of the configurations are as same as in the IMX390 sensor folder.

    I have used this e2e thread as the reference.

    https://e2e.ti.com/support/processors-group/processors/f/processors-forum/924111/ccs-tda4vm-ub960-q1---ub913a-device-driver-create

    There was nothing mentioned with respect to sensor configuration.

    Do we need to add any configuration from our side for establishing the communication with the sensor?

  • Hi Alex,

    If the ub964 itself is not detecting any frame input, then CSIRX will wait on getting frame captured. 

    Can you first check few,

    1, is ub964 detecting input lock? This will tell if the serializer is detected in deserializer?

    2, are you able to read/write serializer registers? Can you write to a register and readback to confirm it is written correctly? 

    3, are you able to read/write serializer registers? 

    4, Is streamon API called to start streaming in the sensor?

    Regards,

    Brijesh

  • Hi Brijesh,

    1. The UB964 0x4D register have the value "13" means LOCK_STS is 1.

    2,3. Read/Write is working in Serialiser side. Below are the prints of serialiser and deserialiser register read.

    Deserialiser:

    [MCU2_0]     35.044383 s: 0x3d Register Read 0x000 : 7a __ 1e 30 c2 1 __ fe 1c 10 79 79 f b0 __ f0
    [MCU2_0]     35.046471 s: 0x3d Register Read 0x010 : 81 85 89 8d __ __ __ __ __ __ __ __ __ __ 4 2
    [MCU2_0]     35.048535 s: 0x3d Register Read 0x020 : e0 3 __ __ __ __ __ __ __ __ __ __ __ __ __ __
    [MCU2_0]     35.050598 s: 0x3d Register Read 0x030 : __ __ 1 3 __ __ __ 3 __ __ __ __ __ __ __ __
    [MCU2_0]     35.052689 s: 0x3d Register Read 0x040 : __ a3 1 1 __ __ __ __ __ __ __ __ 1 13 38 19
    [MCU2_0]     35.054765 s: 0x3d Register Read 0x050 : c6 __ __ __ __ __ __ __ 58 __ __ b0 e8 52 fe __
    [MCU2_0]     35.056851 s: 0x3d Register Read 0x060 : __ __ __ __ __ 80 ff __ __ __ __ __ __ 7f 88 88
    [MCU2_0]     35.058927 s: 0x3d Register Read 0x070 : 1e 2c __ __ __ __ __ c5 __ 1 f ff 20 __ __ __
    [MCU2_0]     35.060989 s: 0x3d Register Read 0x080 : __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __
    [MCU2_0]     35.063058 s: 0x3d Register Read 0x090 : __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __
    [MCU2_0]     35.065121 s: 0x3d Register Read 0x0a0 : __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __
    [MCU2_0]     35.067219 s: 0x3d Register Read 0x0b0 : 10 14 1f 8 25 __ 18 __ ff 3 3 74 __ __ __ __
    [MCU2_0]     35.069292 s: 0x3d Register Read 0x0c0 : __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __
    [MCU2_0]     35.071376 s: 0x3d Register Read 0x0d0 : __ 43 84 2f 60 f8 __ 1 __ __ __ __ __ __ __ __
    [MCU2_0]     35.073443 s: 0x3d Register Read 0x0e0 : __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __
    [MCU2_0]     35.075533 s: 0x3d Register Read 0x0f0 : 5f 55 42 39 36 34 __ __ __ __ __ __ __ __ __ __

    Serialiser:

    [MCU2_0]     35.078666 s: 0x74 Register Read 0x000 : b0 30 20 c5 80 14 7a __ __ __ __ __ 11 55 35 __
    [MCU2_0]     35.081811 s: 0x74 Register Read 0x010 : 17 82 82 __ __ 31 80 __ __ __ __ __ __ a0 fe __
    [MCU2_0]     35.084965 s: 0x74 Register Read 0x020 : e 1c 29 __ __ __ __ __ 25 6 __ __ __ __ __ __
    [MCU2_0]     35.088151 s: 0x74 Register Read 0x030 : __ __ __ fe 80 1 __ __ __ __ __ __ __ __ __ __

    4. Streamon API is used to start streaming.

    Thanks

    Alex

  • Hi Alex,

    Any further update on this issue? 

    Can you read the value at the offset 0x4D multiple times to see if the lock status is not changing? 

    Also is the sensor really powered on? Do we require anything to poweron the sensor or to provide reference clock input? 

    Regards,

    Brijesh

  • Hi Brijesh,

    The issue is resolved and we got the output image.

    Following changes were done to get this output.

    1. For getting the valid and stable PCLK from sensor, 12V input should be supplied to the camera using DES. This is achieved by open J14 and J16 pins and short J35 pins in Deserialiser EVM (DS90UB964).

    After this change the PCLK become stable and same is reflected in Serialiser register (0X0C). Value become 0x15 which means valid PCLK is detected.

    2. In the sensor driver side, the deserialiser register 0x7C is given the value 0xC1.

    3. Data format changed to "FVID2_DF_YUV422I_YUYV" in tivxCaptureExtractDataFormat function at PSDK_RTOS/tiovx/kernels_j7/hwa/capture/vx_capture_target.c

    Thanks for your support.

    Regards,

    Alex