Please note as of Wednesday, August 15th, 2018 this wiki has been set to read only. If you are a TI Employee and require Edit ability please contact x0211426 from the company directory.

Before asking for MFP support

From Texas Instruments Wiki
Jump to: navigation, search

This page is intended to guide you through the support options and help debugging MFP (Codec Engine, Framework Components) issues

Was your question already answered in one of the external resources?


A useful cleanup check:

  • Check carefully the error message:
    • The most common build issue with the Codec Engine examples is that paths to the components that Codec Engine relies on are not set correctly in <user.bld> and <xdcpaths.mak>. This results in the wrong XDCPATH being constructed leading to errors from the XDCTOOLS. Please ensure these paths are set correctly if the build complains about packages not found.
    • If any Codec Engine API returns an error at runtime, the first thing to try is to set the CE_DEBUG environment variable to 2 on Linux-based platforms (e.g. DM6446, DM6467). Look carefully at the log output and read the error message. Typically the messages are detailed enough to give you a sense of what went wrong. Similarly, on DSP-only platforms with the application running in DSP/BIOS you can set up the application to turn on all CE trace using this code in main():
    /* example of how to enable trace */
    #include <ti/sdo/utils/trace/gt.h>
    Void main()
    {
        GT_init(); /* init trace */
 
        /* Set printf function for GT */
        GT_setprintf( (GT_PrintFxn)printf );
        GT_set("*=01234567");   /* Turn on all trace */
    }
    • If the error is seen during codec creation, it may be worth turning on the trace in the Framework Components and rerun the application with the trace turned on to see if there was a resource allocation error. To turn on the trace for DSKT2, DMAN3 and RMAN, etc., simply set the trace (or debug) configuration parameter to true in the server's .cfg (or the application's .cfg file on the non-SOC platforms) file, as described in DSKT2 debugging and DMAN3 debugging. Then rebuild the server and/or application and rerun it to see the detailed trace.


Common pitfalls:

  • Typos! Because codec engine relies on codecs, servers and engines being explicitly named in the .cfg files, it is very easy to mistype these either in the cfg files or in the application in the Engine_open() or codec creation call (e.g. VIDDEC2_create()). A mismatch between the cfg files and the string used in the API calls will cause the Engine_open() call or codec creation to fail. Also the server executable name is specified in the application's .cfg file as well, so make sure that is spelled correctly.
  • Invalid creation parameters or runtime arguments (inArgs, outArgs, dynamicParams) to the codec. Different codecs have different requirements in terms of creation parameters and runtime arguments. Be sure to refer to your codec's documentation to ensure the values you are using are valid.
  • Use the right set of VISA API that corresponds to the codec's XDM version. In other words, if you have a video decoder and it is XDM 0.9 compliant, use the VIDDEC_* APIs. If it is XDM 1.0 compliant, use VIDDEC1_* APIs to interact with it. Find out from your codec vendor which version of XDM they are compliant with.
  • Versioning. Every Codec Engine release was tested with a set of sub-components (e.g. Framework Components, Linux Utils, XDAIS, DSP Link, etc.) with specific version numbers. It is not advised to upgrade Codec Engine without upgrading its dependencies. Always try to use the set that you get from the DVSDK as is. If you upgrade Codec Engine independently of the DVSDK, the drop will contain a 'cetools' subdirectory which contains the new set of subcomponents it has been tested with. Use them.


In general:

  • If you need examples on how to use xDM beyond the Codec Engine examples and the DVSDK demos, take a look at sample applications shipped with the Davinci Multimedia Application Interface (DMAI). Most of them are fairly simple in nature but show the proper 'handshake' in terms of working with xDM-compliant codecs.


If nothing else works:

Useful information to provide together with a description of the issue:

  • Version of Codec Engine and/or Framework Components used
  • Toolset: Version of Linux toolchain, C6000 Code Generation tools, XDCTOOLS (if used)
  • Platform used (e.g. DM6446, DM6437)
  • A test case that can be compiled using either make or Code Composer Studio - this is a key element to enable the reproducibility of the error and pinpoint its exact root.
  • Log of output from CE_DEBUG=2 if running the application on Linux, or log of CE trace output from CCS if running on DSP/BIOS.


Who to contact: