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.

MMWCAS-DSP-EVM: DSP doesn't start after power up

Part Number: MMWCAS-DSP-EVM
Other Parts Discussed in Thread: MMWCAS-RF-EVM

Hi Team,

I'm using the MMWCAS-DSP-EVM board together with the MMWCAS-RF-EVM in cascade mimo configuration and running a modified version of the "cascade radar object detect" use-case.
I've noticed that sometimes after powering the board and booting, the chain doesn't start after calling "chains_cascadeRadarOd_StartApp(&chainsObj);" function.
The function returns correctly and the execution on IPU1_0 continues normally, but seems that DSP just doesn't start (the AlgorithmFxn_RadarDspCascadeMimoProcess() function is not called).
Network Tx link works good and remains waiting for DSP message but nothing is received.

The particular situation only happens sometimes after powering the board, if I simply stop and start again the chain, everything works good (or even if I call the cold reset function). In other words, it happens only in the first execution after power-up the board.


I've already tried to add a big delay before calling the "chains_cascadeRadarOd_Create(&chainsObj.ucObj, &chainsObj);" function but the problem still persist.

Below you have my implementation:

Void Chains_cascadeRadarOd(Chains_Ctrl *chainsCfg)
{
	chain_state = CASCADE_RADAR_NOT_READY;
	chainStart = FALSE;
	chainDone = FALSE;

    Chains_cascadeRadarOdAppObj chainsObj;
    chainsObj.chainsCfg = chainsCfg;

	// Range-FFT parameters configuration
    chainsObj.ucObj.Alg_RadarProcess_fft1Prm =
        (AlgorithmLink_RadarProcessCreateParams *)&chainsObj.radarFftParams1;
    chainsObj.ucObj.Alg_RadarProcess_fft2Prm =
        (AlgorithmLink_RadarProcessCreateParams *)&chainsObj.radarFftParams2;
    chainsObj.ucObj.Alg_RadarProcess_fft3Prm =
        (AlgorithmLink_RadarProcessCreateParams *)&chainsObj.radarFftParams3;
    chainsObj.ucObj.Alg_RadarProcess_fft4Prm =
        (AlgorithmLink_RadarProcessCreateParams *)&chainsObj.radarFftParams4;

	// Object-detection parameters configuration
    chainsObj.ucObj.Alg_RadarProcess_objectDetectPrm =
        (AlgorithmLink_RadarProcessCreateParams *)&chainsObj.radarDspOdParams;

    /* Create links */
    chains_cascadeRadarOd_Create(&chainsObj.ucObj, &chainsObj); //It takes a while

    chain_state = CASCADE_RADAR_READY;

    /* Wait for Start command */
    volatile unsigned int i = 0;
    while (!chainStart)
    {
        BspOsal_sleep(1U);	//1msec
        i++;    //Do something to avoid compiler optimization
    }

#ifdef GPIO_SYNCH2
    /* Prepare GPIO to count sync signals */
    AlgorithmFxn_RadarDspCascadeMimoControlParams ctrlPrms;
    ctrlPrms.baseClassControl.baseClassControl.size = sizeof(ctrlPrms);
    ctrlPrms.baseClassControl.controlCmd = ALGORITHM_LINK_RADAR_PROCESS_CONTROL_CMD;
    ctrlPrms.dspControlCmd = ALGORITHM_FXN_RADAR_DSP_PROCESS_CMD_SET_GPIO;

    ctrlPrms.syncGpioParam = ALGORITHMFXN_RADAR_DSP_PROCESS_INIT_SYNC_GPIO;
    System_linkControl(
            chainsObj.ucObj.Alg_RadarProcess_objectDetectLinkID,
            ALGORITHM_LINK_CMD_CONFIG,
            &ctrlPrms,
            sizeof(ctrlPrms),
            TRUE
    );
#endif

    /* Start app */
    chains_cascadeRadarOd_StartApp(&chainsObj);
    Vps_printf(" CASCADE RADAR UC: Chain Started!!\n");

    chain_state = CASCADE_RADAR_MEASURING;

    /* Wait for Stop command */
    i = 0;
    do
    {
        BspOsal_sleep(10U);	//10msec
        i++;    //Do something to avoid compiler optimization
    }
    while(chainStart && !chainDone);

    /* Stop and delete app */
    chains_cascadeRadarOd_StopAndDeleteApp(&chainsObj);
    Vps_printf(" CASCADE RADAR UC: Chain Stopped!!\n");

    chain_state = CASCADE_RADAR_NOT_READY;
}

Do you have some clue about what is happening here?

Regards,

Pablo.

  • Hi Pablo,

    We have noticed that sometime the on-board FPGAs doesn't start properly so the data is not received by SoC.

    The FPGAs are the bridge chip to convert CSI2 data to parallel data to SoC.

    Unfortunately, the FPGA vendor has not provided a solution for this issue so we don't have a fix other than reboot the board.

    Regards,
    Stanley 

  • Hi Stanley,

    Thanks for your quick reply,  I'm afraid this is not the FPGA case. 

    I've already implemented a quick FPGA boot test:

    Void chains_cascadeRadarOd_SetAppPrms(chains_cascadeRadarOdObj *pUcObj, Void *appObj)
    {
        Chains_cascadeRadarOdAppObj *pObj
            = (Chains_cascadeRadarOdAppObj*)appObj;
        UInt32 portId[SYSTEM_CAPTURE_VIP_INST_MAX] = {
            VPS_CAPT_VIP_MAKE_INST_ID(VPS_VIP1, VPS_VIP_S0, VPS_VIP_PORTA),
            VPS_CAPT_VIP_MAKE_INST_ID(VPS_VIP1, VPS_VIP_S1, VPS_VIP_PORTA),
            VPS_CAPT_VIP_MAKE_INST_ID(VPS_VIP2, VPS_VIP_S0, VPS_VIP_PORTA),
            VPS_CAPT_VIP_MAKE_INST_ID(VPS_VIP2, VPS_VIP_S1, VPS_VIP_PORTA)
        };
        UInt32 i;
    
    	// Check if all FPGAs have started
    	UInt32 flagFpgaOk = 1;
    	UInt32 gpioPinValue;
    	UInt32 fpgaGpioPin[4] = {23U, 26U, 27U, 24U};
        Chains_ar12xxGetSampleCascadeConfig(&pObj->ar12xxCfg);
    	BspOsal_sleep(3000); // Wait three seconds before reading GPIOs
    
    	for (i=0; i<4;i++){
    		gpioPinValue = (GPIOPinRead(SOC_GPIO2_BASE, fpgaGpioPin[i]) >> fpgaGpioPin[i]) & 0x1U;
    		if (gpioPinValue == 1)
    			Vps_printf("FPGA%d OK ", i+1);
    		else if (gpioPinValue == 0){
    			Vps_printf("FPGA%d NOT OK ", i+1);
    			flagFpgaOk = 0;
    		}
    	}	
    	while (flagFpgaOk == 0 ){
    		Vps_printf("FPGA BOOT ERROR: power cycle the board\n");
    		BspOsal_sleep(1000);
    	}
    
        ChainsCommon_ar12xxConfig(&pObj->ar12xxCfg);

    But the problem persists, it seems the chain simply doesn't start sometimes. Network_tx link is working and waiting for some DSP message but nothing happens.

    In which part of the source code can I check if some data is arriving to the DSP?

  • Hi,

    Can you use 'p' option to print statistics from run-time menu?

    Please check if Capture Link is receiving expected frame rate.

    If Capture Link is getting correct input frame rate, that means radar data is coming in.

    Then if DSP is not processing the data, it is an issue on DSP side. DSP may have crashed.

    You can connect to DSP with JTAG in CCS and check.

    However, if Capture Link itself is not receiving data at the correct frame rate, it is an issue with Radar configuration, Radar initialization, or FPGA.

    Regards,
    Stanley