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: Failure About Encoder Hardware Init

Part Number: TDA4VM


Hi Ti's experts,

    We referred to Demo timmlibenc(Path: /sdk/qnx/psdkqa/qnx/codec/img/qnx/encoder/test SDK 8.05 in QNX),  and successfully added the coding function to our application.

    At the same time, we disabled automatic start of processes vxd_dec and vxe_enc.

    But our latest discovery is that there may be occasional “MM_ENC_Init failed” during program operation, like this,

    

    At this time, the encoder cannot operate normally due to this fault. But if I run our application  again, the encoder will initialize successfully

   

   We also received debugging information for tisci-mgr(tisci-mgr -v)  at the same time

  

  It seems that the error exception was caused by the hardware not returning ACK, am i right?

  This problem sometimes occurs during the first running our app, and sometimes after multiple restarts of. 

  Could you please help us to solve this problem, thanks?

   The code for initializing the encoder is as follows

    {
        status = procmgr_ability(0,
        PROCMGR_AOP_ALLOW | PROCMGR_ADN_NONROOT | PROCMGR_AID_KEYDATA,
        PROCMGR_AOP_ALLOW | PROCMGR_ADN_NONROOT | PROCMGR_AID_IO,
        PROCMGR_AOP_ALLOW | PROCMGR_ADN_NONROOT | PROCMGR_AID_MEM_PHYS,
        PROCMGR_AOP_ALLOW | PROCMGR_ADN_NONROOT | PROCMGR_AID_PRIORITY,
        PROCMGR_AOP_DENY  | PROCMGR_ADN_NONROOT | PROCMGR_AOP_LOCK      | PROCMGR_AID_EOL);

        if (status != VX_SUCCESS)
        {
            CALMCAR_ERROR("Unable to gain procmgr abilities for nonroot operation.{}", status);
            return status;
        }

        mm_status = ThreadCtl(_NTO_TCTL_IO, 0);
        if (mm_status != VX_SUCCESS)
        {
            CALMCAR_ERROR("Unable to ThreadCtl.{}", mm_status);
            return status;
        }

        mm_enc_init_params init_params = {0};
        MM_ENC_SetDefaultInitParams(&init_params);

        mm_status = MM_ENC_Init(&init_params);
        if(MM_SUCCESS != mm_status) 
        {
            CALMCAR_ERROR("Error: MM_ENC_Init failed {}", mm_status);
        }
        else
        {
            venc_ctrl.intra_pred_modes = encoder_params->intra_pred_modes;
            mm_status = MM_ENC_Create(&venc_params, &venc_ctrl, &encoder_obj->channel_id);
        }

        if(MM_SUCCESS != mm_status)
        {
            CALMCAR_ERROR("MM_ENC Create failed {}", mm_status);
            status = VX_FAILURE;
        }
    }

    if (VX_SUCCESS == status)
    {
        mm_status = MM_ENC_RegisterCb(DvrErrorCb, encoder_obj->channel_id, (void *)encoder_obj);

        if(MM_SUCCESS != mm_status)
        {
            CALMCAR_ERROR("MM_ENC Register Callback failed {}", mm_status);
            status = VX_FAILURE;
        }
    }

    if (VX_SUCCESS == status)
    {
        mm_status = MM_ENC_StartStreaming(encoder_obj->channel_id, MM_BUF_TYPE_VIDEO_OUTPUT);
        mm_status |= MM_ENC_StartStreaming(encoder_obj->channel_id, MM_BUF_TYPE_VIDEO_INPUT);

        if (MM_SUCCESS != mm_status)
        {
            CALMCAR_ERROR("MM_ENC Start Streaming failed");
            status = VX_FAILURE;
        }
    }

   

   Best Wishes

    

     

  • Hello,

    Thank you for sharing info regarding your setup. 8.5 is a relatively new release that supports IMG codec using the OMX component and a resource manager. From the description it looks like in your setup, the resource manager is not used but the timmlibenc is being used to get the encoder functionality. Is this understanding correct? The resource manager is intended to be the driver for the encoder hardware and will help support multi-instance use cases seamlessly.

    Coming to the issue that you are seeing it looks to be a SciClient request failing. Do try out the attached sciclient patch (which was fixed in 8.6 release) /cfs-file/__key/communityserver-discussions-components-files/791/sciclient_2D00_contiguous_2D00_buffer_2D00_requests.patch on top of the 8.5 release.

    Best Regards

    Subbu

  • Hello, Subbu

    Thanks for your sciclient patch, I have tested least 200 times and did not reproduce the problem again.

    I have some other questions, could you please help me answer them?

    1.Our program does not need to write encoded data to a file, is it necessary to add the funtion procmgr_ability()?
    2.ThreadCtl(_NTO_TCTL_IO, 0),this function seems to be requesting IO permissions, Is this necessary for the encoder?

            status = procmgr_ability(0,
            PROCMGR_AOP_ALLOW | PROCMGR_ADN_NONROOT | PROCMGR_AID_KEYDATA,
            PROCMGR_AOP_ALLOW | PROCMGR_ADN_NONROOT | PROCMGR_AID_IO,
            PROCMGR_AOP_ALLOW | PROCMGR_ADN_NONROOT | PROCMGR_AID_MEM_PHYS,
            PROCMGR_AOP_ALLOW | PROCMGR_ADN_NONROOT | PROCMGR_AID_PRIORITY,
            PROCMGR_AOP_DENY  | PROCMGR_ADN_NONROOT | PROCMGR_AOP_LOCK      | PROCMGR_AID_EOL);
    
            if (status != VX_SUCCESS)
            {
                CALMCAR_ERROR("Unable to gain procmgr abilities for nonroot operation.{}", status);
                return status;
            }
    
            mm_status = ThreadCtl(_NTO_TCTL_IO, 0);
            if (mm_status != VX_SUCCESS)
            {
                CALMCAR_ERROR("Unable to ThreadCtl.{}", mm_status);
                return status;
            }

    Best Wishes

  • Hello,

    I did look at the various abilities that we set in detail and made sure they are all needed. The _NTO_TCTL_IO might not be a big deal for 8.05 release, but is necessary since with the newer implementation (9.x ) where we do enable and disable interrupts.

    Hope this clarifies your query.

    BR

    Subbu