J784S4XEVM: CSI UDMA Issue During Reboot Test

Hojung Bae

Prodigy 120 points

Part Number: J784S4XEVM

Hello,

I have a question regarding an intermittent CSI UDMA-related error.

(SDK Version : RTOS 11.01, Linux: 11.01)

(boot_app Boot Mode)

During CSI testing, I am running repeated reboot tests, and I occasionally see a UDMA-related error.

In my implementation, the RX task initializes UDMA, and the TX task only uses the UDMA handle initialized by the RX task.


// RX Task
static int32_t CsirxApp_init(Csi_commonObj* appCommonObj)
{
    int32_t retVal = FVID2_SOK, dmaStatus = UDMA_SOK;
    Udma_DrvHandle drvHandle;
    Udma_InitPrms   udmaInitPrms;
    Fvid2_InitPrms initPrms;

        /* Fvid2 init */
    Fvid2InitPrms_init(&initPrms);
    initPrms.printFxn = &App_fvidPrint;
    retVal = Fvid2_init(&initPrms);
    if (FVID2_SOK != retVal)
    {
        GT_0trace(CsirxAppTrace, GT_ERR,
                  APP_RX_NAME ": Fvid2 Init Failed!!!\r\n");
    }

    drvHandle = &appCommonObj->udmaDrvObj;
    UdmaInitPrms_init(UDMA_INST_ID_BCDMA_0, &udmaInitPrms);
    udmaInitPrms.printFxn = &App_dmaPrint;
    dmaStatus = Udma_init(drvHandle, &udmaInitPrms);
    if(UDMA_SOK != dmaStatus)
    {
        retVal = FVID2_EFAIL;
        GT_0trace(CsirxAppTrace, GT_ERR,
                  APP_RX_NAME ": UDMA Init Failed!!!\r\n");
    }

// TX Task
static int32_t CsitxApp_init(Csi_commonObj* appCommonObj)
{
    int32_t retVal = FVID2_SOK;
    Udma_DrvHandle drvHandle;

    Csitx_initParamsInit(&appCommonObj->txinitPrms);
    drvHandle = &appCommonObj->udmaDrvObj;

    appCommonObj->txinitPrms.drvHandle = drvHandle;      
    retVal = Csitx_init(&appCommonObj->txinitPrms);
    if (FVID2_SOK != retVal)
    {
        GT_0trace(AppTrace, GT_ERR,
                  APP_TX_NAME ": System Init Failed!!!\r\n");
    }


    return (retVal);
}

The TX task waits for the RX initialization using Semaphore_pend().
After the RX task completes initialization, it sends Semaphore_post() to the TX task and then calls Fvid2_start().

Once the TX task receives the semaphore from the RX task, it proceeds with its own initialization and then calls Fvid2_start().

The error message is shown below.
There is no fixed pattern, but it occurs roughly once after about 30 reboot test cycles.

CSI_RX_TASK:===================Setup Details===================
csi/csi_rx_func.c @ Line 338: CSI_RX_TASK: Three Capture Instance 0, 1, 2 instance
CSI_RX_TASK: Capture DF:0x2a
CSI_RX_TASK: Capture Resolution:1024 x 131
CSI_RX_TASK:===================================================

Clock Freq: CSITX_MOD_ESC_CLK = 20000000Hz
Clock Freq: CSITX_MOD_DPHY_TXBYTECLKHS_CLK = 0Hz
Clock Freq: CSITX_MOD_VBUS_CLK = 250000000Hz
Clock Freq: CSITX_MOD_MAIN_CLK = 500000000Hz
CSI_RX_TASK:Set D-PHY Configuration Successful for CSIRX instance 0!!!
CSI_RX_TASK:Error Events Registration Successful for CSIRX instance 0!!!
CSI_RX_TASK: CSIRX Capture created for CSIRX instance 0
CSI_RX_TASK:Set D-PHY Configuration Successful for CSIRX instance 1!!!
CSI_RX_TASK:Error Events Registration Successful for CSIRX instance 1!!!
CSI_RX_TASK: CSIRX Capture created for CSIRX instance 1
CSI_RX_TASK:Set D-PHY Configuration Successful for CSIRX instance 2!!!
CSI_RX_TASK:Error Events Registration Successful for CSIRX instance 2!!!
CSI_RX_TASK: CSIRX Capture created for CSIRX instance 2
[UDMA] [Error] Sciclient event config failed!!!
[UDMA] [Error] Event config failed!!
[UDMA] Assertion @ Line: 991 in src/udma_event.c: (UDMA_EVENT_INVALID != vintrNum) : failed !!!
[UDMA] [Error] Sciclient event config failed!!!
[UDMA] [Error] Event config failed!!
src/csitx_drvUdma.c @ Line 332: [ERROR]UDMA CQ event register FAILED!!!
src/csitx_drv.c @ Line 345: Instance create failed!!!
src/csitx_drv.c @ Line 1392: [ERROR]UDMA channel close FAILED!!!
src/csitx_drv.c @ Line 1392: [ERROR]UDMA channel close FAILED!!!
src/csitx_drv.c @ Line 1392: [ERROR]UDMA channel close FAILED!!!
src/csitx_drv.c @ Line 1392: [ERROR]UDMA channel close FAILED!!!
src/csitx_drv.c @ Line 376: Create failed for given configuration
src/fvid2_drvMgr.c @ Line 777: Driver create failed!!

Could you please advise what might be causing this issue, or if there is any recommended solution or workaround?

5 months ago

0 Tanmay Patil 5 months ago

TI__Mastermind 43890 points

Hi,

Our expert is currently out of office. Please expect a delay in response.

Regards,
Tanmay

0 Jared McArthur 4 months ago in reply to Tanmay Patil

TI__Mastermind 28910 points

HI Hojung Bae,

Can you test creating a different handle for the CSI-TX?

Best,
Jared

0 Hojung Bae 4 months ago in reply to Jared McArthur

Prodigy 120 points

Hi Jared,

Are you suggesting that I should use a different UDMA instance instead of UDMA_INST_ID_BCDMA_0, so that TX can use its own separate UDMA?

Currently, I am already using UDMA_INST_ID_MAIN_0 to copy the received CSI data,

UDMA_INST_ID_MCU_0 using ETH, so I cannot use it for TX.

Are there any other UDMA instances available that I can use?

0 Jared McArthur 4 months ago in reply to Hojung Bae

TI__Mastermind 28910 points

Hi Hojung Bae,

No, the UDMA instance should remain UDMA_INST_ID_BCDMA_0. On another look, there doesn't seem to be an issue with the interactions between the CSI-RX, CSI-TX, and UDMA.

It looks like the error is occurring during the UDMA initialization, correct? Is there

Can you send the logs of a working run/example?

The error message: "[UDMA] [Error] Sciclient event config failed!!!" is usually seen due to resource allocation errors. Have you changed anything regarding resource allocation?

Best,
Jared

0 Hojung Bae 4 months ago in reply to Jared McArthur

Prodigy 120 points

There have been no changes related to the UDMA configuration.

Other than calling UdmaInitPrms_init() and Udma_init(), I did not make any additional UDMA-related changes. I mostly implemented the code by referring to the existing drv/csitx and drv/csirx code.

Below is the log from a working run.

root@j784s4-evm:~# cat /sys/kernel/debug/remoteproc/remoteproc3/trace0
CSI RX PMSet 0
CSI_RX_TASK: CSI Task - STARTS !!!
CSI_RX_TASK:===================Setup Details===================
csi/csi_rx_func.c @ Line 351: CSI_RX_TASK: Three Capture Instance 0, 1, 2 instance
CSI_RX_TASK: Capture DF:0x2a
CSI_RX_TASK: Capture Resolution:1024 x 131
CSI_RX_TASK:===================================================
CSI_RX_TASK:Set D-PHY Configuration Successful for CSIRX instance 0!!!
CSI_RX_TASK:Error Events Registration Successful for CSIRX instance 0!!!
CSI_RX_TASK: CSIRX Capture created for CSIRX instance 0

Clock Freq: CSITX_MOD_ESC_CLK = 20000000Hz
Clock Freq: CSITX_MOD_DPHY_TXBYTECLKHS_CLK = 0Hz
Clock Freq: CSITX_MOD_VBUS_CLK = 250000000Hz
Clock Freq: CSITX_MOD_MAIN_CLK = 500000000Hz
IPC_Setup (core : mcu2_0 3) .....
CSI_RX_TASK:Set D-PHY Configuration Successful for CSIRX instance 1!!!
CSI_RX_TASK:Error Events Registration Successful for CSIRX instance 1!!!
CSI_RX_TASK: CSIRX Capture created for CSIRX instance 1
CSI_RX_TASK:Set D-PHY Configuration Successful for CSIRX instance 2!!!
CSI_RX_TASK:Error Events Registration Successful for CSIRX instance 2!!!
CSI_RX_TASK: CSIRX Capture created for CSIRX instance 2
CSI_TX_TASK: CSITX DRV created
CSI_TX_TASK: CSITX start of frame interrupts for CSITX instance:1 in 10 sec is 1!!!
IPC_MPU1_0 Start...
IPC_Setup done .....

0 Suman Anna 4 months ago in reply to Hojung Bae

TI__Guru*** 127335 points

Hi Hojung,

Jared is on vacation until end of next week, so responses will be delayed on this thread.

In anycase, I have taken a look at this thread, and I suspect the symptoms are all pointing to a missing variable initialization, cleanup or some re-initialization step.

Are you running the test repeatedly in a loop, or a proper reboot? If it is indeed the latter, then the RM state-machine should be from reset, and all the RM requests should yield the exact same resources on every run. There are no questions of resource leaks etc.

Please ensure that your global variables are all initialized properly, this would typically be dictated by your linker settings.

regards

Suman

0 Hojung Bae 4 months ago in reply to Suman Anna

Prodigy 120 points

Hi Suman,

There are two types of reboot tests I have performed.

The first one is an automated test using a macro, where the Linux reboot command is executed repeatedly. The second one is a manual test using the Reset button on the EVM board.

I am not running the test repeatedly in a loop inside the application.

The issue occurs in both cases, regardless of whether the system is rebooted using the Linux reboot command or reset using the EVM Reset button.

Regarding global variables, except for semaphores and the actual data buffers, the main global object is almost only Csi_commonObj gAppCommonObj;, which contains the TX/RX instance objects.

For now, I will check the global variable initialization once again. thank you

/* ========================================================================== */

/* Global Variables */

/* ========================================================================== */

/* App common object */

extern Csi_commonObj gAppCommonObj;

/* CSIRX instances to use in application */

uint32_t gAppCapInst[CSIRX_INSTANCE_ID_MAX] = { CSIRX_INSTANCE_ID_0, CSIRX_INSTANCE_ID_1, CSIRX_INSTANCE_ID_2 };

/* Memory buffer to hold data */

uint8_t gFrmDropBuf[APP_TOTAL_CAPT_INST][(APP_RX_FRAME_PITCH)] __attribute__(( aligned(128), section(".data_buffer")));

uint8_t gFrms[APP_TOTAL_CAPT_INST][(APP_RX_FRAMES_PER_CH * APP_RX_CH_NUM)][APP_RX_FRAME_SIZE] __attribute__(( aligned(128), section(".data_buffer")));

uint8_t gRxInst0Buf[(APP_RX_FRAMES_PER_CH * APP_RX_CH_NUM)][APP_RX_FRAME_SIZE] __attribute__(( aligned(128), section(".csi0_data_buffer")));

uint8_t gRxInst1Buf[(APP_RX_FRAMES_PER_CH * APP_RX_CH_NUM)][APP_RX_FRAME_SIZE] __attribute__(( aligned(128), section(".csi1_data_buffer")));

uint8_t gRxInst2Buf[(APP_RX_FRAMES_PER_CH * APP_RX_CH_NUM)][APP_RX_FRAME_SIZE] __attribute__(( aligned(128), section(".csi2_data_buffer")));

csi_config_t gRxCfgBuf[APP_TOTAL_CAPT_INST] __attribute__(( aligned(32), section(".csi_config_buffer")));

extern uint8_t gTxFrms[APP_TX_TEST_INST_NUM][(APP_TX_FRAMES_PER_CH * APP_TX_CH_NUM)][APP_TX_FRAME_SIZE];

/* Semaphore to indicate app completion */

SemaphoreP_Handle gAppRxReadySem;

extern SemaphoreP_Handle gAppTxReadySem;

static SemaphoreP_Handle gRxDoneSem[APP_TOTAL_CAPT_INST];

static uint8_t gCsiRxDoneStack[APP_TOTAL_CAPT_INST][CSIRX_DONE_STACKSIZE] __attribute__((aligned(32)));

#if defined(FREERTOS)

/* Capture test Task handle */

extern TaskP_Handle gCsirxTask;

#endif

0 Suman Anna 4 months ago in reply to Hojung Bae

TI__Guru*** 127335 points

Hi Hojung,

Hojung Bae said:
For now, I will check the global variable initialization once again. thank you

Ok, sure.

The TI SDKs provide some utility tests as part of Vision Apps. I encourage you to leverage those for whatever you are trying to test.

I hope you are building your test application using the Vision Apps frameworks.

regards

Suman

Processors

Processors forum

J784S4XEVM: CSI UDMA Issue During Reboot Test