TDA4AEN-Q1: TDA4 CSITX output display jitter

gg yang

Part Number: TDA4AEN-Q1

Tool/software:

Hi,

cam1 yuv422 1080p 30Hz/60Hz----->soc------->csitx--30/60hz---->max96717------>LVDS------>max9296------mipi---30/60Hz--->LCD Controller---->LVDS Display.

TDA4entry CSITX output display jitter

The frame rate signal of TDA4entry CSITX output oscilloscope has a jitter of about 30us.

Is this the cause of display jitter?
How to prevent frame rate signal jitter in SOC CSTTX output?

LCD Controller IC manufacturers believe that screen shake is caused by unstable frame signals.

over 1 year ago

0 Fabiana Jaimes over 1 year ago

TI__Mastermind 19670 points

Hi,

Due to a holiday, half of our team is currently out of office. Please expect a 1~2 delay in responses.

Apologies for the delay and thank you for your patience.

-Fabiana

0 Brijesh Jadav over 1 year ago in reply to Fabiana Jaimes

TI__Guru**** 486985 points

Hi gg yang,

Not sure which release you are using, but in SDK10.0, i see below change in kernels/video_io/host/vx_csitx_host.c file, in tivx_csitx_params_init API. Can you please see if you have these change?

#elif defined(SOC_J722S)
prms->instCfg[loopCnt].fifoDepth = 192U;
#endif

Regards,

Brijesh

0 gg yang over 1 year ago in reply to Brijesh Jadav

Expert 1280 points

Hi.Brijesh

TDA4entry SDK9.02.05. ADAS.

#elif defined(SOC_J722S)
prms->instCfg[loopCnt].fifoDepth = 192U;
#endif

I have fixed it

Now YUV422 1080p 30Hz CSITX can output correct content.
However, RGB888 1080P at 25fps or 30fps only outputs one frame of abnormal data.

Will not output new data.
I have the same effect using both receiving devices.

CSITX config:

csitx_config_laneBandSpeed 0x8
csitx_config_laneSpeedMbps 600
csitx_config_vBlank 22
csitx_config_hBlank 40
csitx_config_startDelayPeriod 40

Regards,

0 Brijesh Jadav over 1 year ago in reply to gg yang

TI__Guru**** 486985 points

Hi gg yang,

gg yang said:
However, RGB888 1080P at 25fps or 30fps only outputs one frame of abnormal data.

Sorry did not get it. It does not output at all or it output one frame of wrong data? Are the subsequent frames correct, after the first incorrect frame?

Also Is the input in RGBx32 format? Because CSITX does not support RGB888 packed format.

Regards,

Brijesh

0 gg yang over 1 year ago in reply to Brijesh Jadav

Expert 1280 points

Hi Brijesh

input RGBA888,
If it is RGB888, then CSITX prompts that the input data format is invalid during runtime

Only output one frame of incorrect data repeatedly.
RGBA output from egl mosaic, then input to CSITX node.

1. TDA4entry---1080p 30 fps yuv422 ---->csitx--4lane---->max96717------->max9296----->dispaly OK

2. TDA4entry---1080p 30 fps RGBA888---->csitx--4lane---->max96717------->max9296----->dispaly （Only one frame of incorrect image or black screen can be displayed.）

Serializer output pattern 1920x1080 RGB888 is displaying normally.

csitx--4lane---->max96717（1080P RGB888 pattern）---->max9296----->dispaly OK.

Regards,

0 Brijesh Jadav over 1 year ago in reply to gg yang

TI__Guru**** 486985 points

Hi gj,

Strange, there should not be difference between YUV and RGB format, other than color formats itself. when you say incorrect image, does it mean the image data is correct, but may be due to format issue, like pitch and/or size, it is sent out incorrectly? Also does serializer report any error for the incoming stream on RGB data? Is it configured to expect RGB888 MIPI data?

Regards,

Brijesh

0 gg yang over 1 year ago in reply to Brijesh Jadav

Expert 1280 points

Hi.Brijesh

egl mosaic--RGBA8888--->csitx------>serializer-------->deserializer-----display.

When the deserializer pattern is displaying normally, set the deserializer register to turn off the pattern and output the deserializer data.

No errors were found when reading the serial register.

0 Brijesh Jadav over 1 year ago in reply to gg yang

TI__Guru**** 486985 points

Hello gg yang,

but that means there is no setup issue on the CSITX side, because there is any setup issue, you would have seen the issue even after pattern is removed from deserializer. isn't it?

Does serializer or deserializer require specific sequence in this case? or does it require specific configuration?

Regards,

Brijesh

0 gg yang over 1 year ago in reply to Brijesh Jadav

Expert 1280 points

Hi.Brijesh

I think now it can be explained that both the serializer and deserializer configurations are reconfigured sequences.
Now the display is showing data, and some of the data is constantly changing.

It is correct to save RGBA8888 image data before sending from CSITX. The configuration of the deserializer is also verified to be correct using the serializer pattern data. I also confirmed with the serializer manufacturer that the configuration of the serializer can output correctly according to the mode. The serializer is unlikely to change its data functionality again.

CSITX or serializer converts a lot of data into 0 ?

0 Brijesh Jadav over 1 year ago in reply to gg yang

TI__Guru**** 486985 points

Hi gg yang,

I am sorry, but i dont understand this video. i dont see much data in the video. its all black frame..

Well, it may not make data to 0, but if some configuration is incorrect, it may not be detecting it correctly. So can we please check if there is any status register in the serializer to confirm it is receiving data and is matching with the data type set in the frame?

Regards,

Brijesh

0 gg yang over 1 year ago in reply to Brijesh Jadav

Expert 1280 points

Hi，Brijesh
Confirmed that the status of the serializers is correct.

Regards,

0 Brijesh Jadav over 1 year ago in reply to gg yang

TI__Guru**** 486985 points

Hi gg yang,

But what do you see in the output?

Regards,

Brijesh

0 gg yang over 1 year ago in reply to Brijesh Jadav

Expert 1280 points

I see some bright spots with flickering changes
We need to verify that the data sent by CSITX is correct.

Have you tested whether the data values sent by CSITX to RGB888 are correct?

0 Brijesh Jadav over 1 year ago in reply to gg yang

TI__Guru**** 486985 points

Hi gg yang,

We dont have anything connected over CSITX on EVM, so it is not possible to verify CSITX on EVM.

Few more questions,

- Can you please check and confirm that control mmr register CTRL_MMR0_CFG0_DPHY_TX0_CTRL is set to value 0x1? This is required for DPHY to be used for CSITX. Since this is working fine for YUV, most likely it should have been set.

- For 1920x1080 RGB24 25fps output, it requires total 1.3Gbps total lane speed, can you please check and confirm it is set to sufficient lane speed?

- It seems that it is reading some incorrect pixels. I am just wondering if there is any change required in QOS settings. Can you please try making a small change? In the API Csitx_chCfgInit, in the file packages\ti\drv\csitx\src\csitx_drvInit.c, can you please make below change and see if it helps?

chCfgPrms->txChParams.busOrderId = 12U;

Regards,

Brijesh

0 gg yang over 1 year ago in reply to Brijesh Jadav

Expert 1280 points

Hi，Brijesh

1.CTRL_MMR0_CFG0_DPHY_TX0_CTRL 为1

2 The mipi speed of CSITX and deserializer is sufficient

CSITX config:

csitx_config_laneBandSpeed 0x8
csitx_config_laneSpeedMbps 600
csitx_config_vBlank 22
csitx_config_hBlank 40
csitx_config_startDelayPeriod 40

deserializer mipi data lane speed 1.6Gbps

Change to chCfgPrms ->txChParams. busOrderId=12 U;, YUV display is normal. RGB remains the same as before, with no changes and almost all data being 0. The frame rate of 25 is also consistent with the frame rate output rgb888 by CSITX.

Regards,

0 Brijesh Jadav over 1 year ago in reply to gg yang

TI__Guru**** 486985 points

hi gj,

From where are you getting the input frame for CSITX? Are you filling this up from the application? I see just black image with white dots moving around.

Have you taken care of cache operation before submitting the frame to CSITX?

Regards,

Brijesh

0 gg yang over 1 year ago in reply to Brijesh Jadav

Expert 1280 points

Hi Brijesh

When the receiving application of the deserializer sees the frame rate,
There was no cache before CSITX.

Regards,

0 Brijesh Jadav over 1 year ago in reply to gg yang

TI__Guru**** 486985 points

Hi gg yang,

ok, the question is, which module is feeding to CSITX? is the input coming from GPU? or this is generated by CPU/R5F?

Regards,

Brijesh

0 gg yang over 1 year ago in reply to Brijesh Jadav

Expert 1280 points

GPU egl mosaic node feeding to CSITX.

0 Brijesh Jadav over 1 year ago in reply to gg yang

TI__Guru**** 486985 points

but why is then blank? If GPU is generating output for CSITX, it should not be blank, isn't it?

Regards,

Brijesh

0 gg yang over 1 year ago in reply to Brijesh Jadav

Expert 1280 points

Save rgba8888 the GPU output image as a file and confirm that it is correct.

+1 Brijesh Jadav over 1 year ago in reply to gg yang

TI__Guru**** 486985 points

ok, so the issue is not just white dots flashing in the image, but also the image itself is incorrect.

I think i know the reason for this failure. Can you please make few changes in the driver and try it out?

In the API CsitxDrv_udmaTxTrpdInit, in the file mcu_plus_sdk_j722s_09_02_00_41\source\drivers\csitx\v0\src\csitx_drvUdma.c,

please replace

CSL_UdmapTR1 *pTr = (CSL_UdmapTR1 *)(pTrpdMem + sizeof(CSL_UdmapTR15));

with

CSL_UdmapTR1 *pTr = UdmaUtils_getTrpdTr1Pointer((uint8_t *)pTrpdMem , 0U);

Essentially, replace this API with below code

int32_t CsitxDrv_udmaTxTrpdInit(Udma_ChHandle txChHandle,
                                uint8_t *pTrpdMem,
                                const uint32_t *srcBuf,
                                const Csitx_ChCfg *chCfg,
                                uint32_t chIdx)
{
    int32_t retVal = FVID2_SOK;
    CSL_UdmapCppi5TRPD *pTrpd = (CSL_UdmapCppi5TRPD *) pTrpdMem;
    uint32_t descType = (uint32_t)CSL_UDMAP_CPPI5_PD_DESCINFO_DTYPE_VAL_TR;
    uint32_t cqRingNum = Udma_chGetCqRingNum(txChHandle);
    CSL_UdmapTR1 *pTr = UdmaUtils_getTrpdTr1Pointer((uint8_t *)pTrpdMem , 0U);
    uint32_t *pTrResp =
                (uint32_t *) (pTrpdMem + (sizeof(CSL_UdmapTR15) *
                                         (1U + 1U)));

    /* Setup descriptor */
    UdmaUtils_makeTrpd((uint8_t *)pTrpdMem, UDMA_TR_TYPE_1, 1U, cqRingNum);
    /* Perpetual reload */
    UdmaUtils_setTrpdReload((uint8_t *)pTrpdMem,FALSE , 0);
    
    pTr = UdmaUtils_getTrpdTr1Pointer((uint8_t *)pTrpd, 0U);
    
    /* Initialize TR packet: Start */
    /* Setup TR */
    /* Bit fields::
       Bit No.->Info
       3:0->Type: 2D transfer
       7:6->Event Size: Event is only generated with the TR is complete
       9:8->Trigger0: No Trigger
       10:11->Trigger0 Type:
                    The second inner most loop (ICNT1) will be decremented by 1.
       13:12->Trigger1: No Trigger
       15:14->Trigger1 Type:
                    The second inner most loop (ICNT1) will be decremented by 1.
       23:16->Command ID: The Command ID for the TR
       31:24->Conf Flags: Configuration Specific Flags
       */
    pTr->flags = 0U;
    pTr->flags   |= CSL_FMK(UDMAP_TR_FLAGS_TYPE,
                            CSL_UDMAP_TR_FLAGS_TYPE_2D_DATA_MOVE);
    pTr->flags   |= CSL_FMK(UDMAP_TR_FLAGS_STATIC, FALSE);
    /* EOP and EOL should be enabled as PSIL/SHIM expects these packets to
       mark the dimensions of the frame for transmission. */
    /* EOL is set to 'CSL_UDMAP_TR_FLAGS_EOL_ICNT0', this is due to ICNT0 is
       equal to the line size. EOL packet has to be sent out for each line of
       the frame. */
    pTr->flags   |= CSL_FMK(UDMAP_TR_FLAGS_EOL, CSL_UDMAP_TR_FLAGS_EOL_ICNT0);
    pTr->flags   |= CSL_FMK(UDMAP_TR_FLAGS_EOP, 1U);
    pTr->flags   |= CSL_FMK(UDMAP_TR_FLAGS_EVENT_SIZE,
                            CSL_UDMAP_TR_FLAGS_EVENT_SIZE_COMPLETION);
    pTr->flags   |= CSL_FMK(UDMAP_TR_FLAGS_TRIGGER0,
                            CSL_UDMAP_TR_FLAGS_TRIGGER_NONE);
    pTr->flags   |= CSL_FMK(UDMAP_TR_FLAGS_TRIGGER0_TYPE,
                            CSL_UDMAP_TR_FLAGS_TRIGGER_TYPE_ALL);
    pTr->flags   |= CSL_FMK(UDMAP_TR_FLAGS_TRIGGER1,
                            CSL_UDMAP_TR_FLAGS_TRIGGER_NONE);
    pTr->flags   |= CSL_FMK(UDMAP_TR_FLAGS_TRIGGER1_TYPE,
                            CSL_UDMAP_TR_FLAGS_TRIGGER_TYPE_ALL);
    pTr->flags   |= CSL_FMK(UDMAP_TR_FLAGS_CMD_ID, chIdx);
    pTr->flags   |= CSL_FMK(UDMAP_TR_FLAGS_SA_INDIRECT, 0U);
    pTr->flags   |= CSL_FMK(UDMAP_TR_FLAGS_DA_INDIRECT, 0U);
    pTr->icnt0    = CsitxDrv_getIcnt0(chCfg);
    pTr->icnt1    = (uint16_t)(chCfg->inFmt.height);
    pTr->dim1     = (uint32_t)(chCfg->inFmt.pitch[0U]);
    /* Destination address does not needed to be programmed,
       this will overwritten in Queue */
    pTr->addr     = (uint64_t) srcBuf;

    /* Clear TR response memory */
    *pTrResp = 0xFFFFFFFFU;
    /* Initialize TR packet: End */
    /* Writeback cache */
    CsitxDrv_cacheWb(pTrpdMem,
                     CSITX_DRV_TRPD_SIZE_ALIGN);
    /* check if line size is greater than pitch provided, pitch should be
       equal to or more than line size in bytes */
    if ((pTr->icnt0 > pTr->dim1) || (pTr->icnt0 == 0U))
    {
        retVal = FVID2_EFAIL;
    }

    return retVal;
}

in the CsitxDrv_queue API in the mcu_plus_sdk_j722s_09_02_00_41\source\drivers\csitx\v0\src\csitx_drv.c file,

please replace

/* Update TR packet descriptor for given Frame */
pTr = (CSL_UdmapTR1 *)((uint8_t *)qObj->trpd +
sizeof(CSL_UdmapTR15));

with

pTr = UdmaUtils_getTrpdTr1Pointer((uint8_t *)qObj->trpd, 0U);

Can you please try with above two changes and see if we can get the correct output from CSITX?

Regards,

Brijesh

Processors

Processors forum

TDA4AEN-Q1: TDA4 CSITX output display jitter