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.

RTOS/DM3725: Error_raiseX debugging for Field Crash Issue

Part Number: DM3725
Other Parts Discussed in Thread: SYSBIOS,

Tool/software: TI-RTOS

XDC version: xdctools_3_30_06_67_core

SYSBIOS Version: bios_6_42_03_35

Compiler Version: ti-cgt-c6000_8.0.1

Hardware: DM3725 

My code is raising an Error_raiseX which calls Error_policyFxn as per the Error.c file... I wanted to know  which module has raised the error? the eb block will be null... I would also need all Register information and NRP,IRP and other details like in case of exception.. that data will be printed in my logging tool so that i can analyse this issue offline and I dont have to depend on CCS and ROV... Any input on how to make this debugging smooth without CCS and ROV...??

Regards

John

  • John,
    the default Error_policyFxn logs each raised error, and the logged data include the module's id. If you are debugging outside of CCS and you don't use ROV, you would have to decode module ids from the config C file generated for your application. That file is usually in the directory package/cfg in your build directory. If you search for Module__id__C, you'll be able to see ids for all modules.
    Are you using the default Error_policyFxn? Which logger are you using?

    The Error module doesn't record any register information, so I don't see how you would use that module as a tool to capture the CPU state. You could figure out where the error is coming from and then change that code to raise an exception, but it seems you are looking for a more generic solution that won't require changing your code. Is that correct?
  • Hi Sasha,

    Thank you for your quick response....I could see this following thing in app_pe64P.c is this what you are referring...?? ..  Module__id__C = (xdc_Bits16)0x2a 

    /* Module__id__C */
    #pragma DATA_SECTION(ti_sysbios_hal_Timer_Module__id__C, ".const:ti_sysbios_hal_Timer_Module__id__C");
    __FAR__ const CT__ti_sysbios_hal_Timer_Module__id ti_sysbios_hal_Timer_Module__id__C = (xdc_Bits16)0x2a;

    Error_raiseX  function has Error_Block *eb, Types_ModuleId mod CString file Int line Error_Id id  IArg arg1, IArg arg2 

    I don't have a Problem to modify the code and also XDC files or Sysbios files I can recompile ... but I just want to make sure my debugging is without CCS and ROV and I don't have to depend on this as I need to solve bugs in Filed issue with log information (I have my own logging framework)

    I can use this data and recompile Error.c file  and use my logging api to log certain info like MOD id Cstring file Error ID ... could you help me whats Error ID ? can we convert that to String in readable form.. Cstring file in CCS also gives null even if its custom build with -Dxdc_FILE=__FILE__

    Regards

    John

  • One of your initial questions was how to use log contents to find out which module raised an error. I don't know yet if you are using the default Error_policyFxn and which logger you are using, but your log probably contains the info normally logged by the default Error_policyFxn. That means, you have the module id and the line number available. From there, you can match the module id with one of the Module__id__C values from the config C file. Now, you know the module and the file line number, so you should be able to detect the exact piece of code that generated the error.

    Error_Ids are also constants generated in the config C file. From and Error_Id in your log, you can find out a corresponding Error by chopping off the lower 16 bits and then search in the config C file for the decimal value from the upper 16 bits. All error ids are of the type xdc_runtime_Error_Id. This all sounds complicated because you are trying to replicate the work that CCS and ROV would do for you, but you should be able to automate this lookup if this is how you are planning to debug errors.

    Normally, Error_ids are connected to error messages, but these error messages are not standard C strings that you can look up in memory using Error_ids. These strings are managed by the module Text, which keeps and array of these strings and retrieves them when asked by other modules. For an example, look at Log_doPrint in xdc/runtime/Log.c. But, I would leave that part for later. In the beginning, just verify that you can find an Error in the config C file from its Error_Id. This is how an Error looks like in that file:
    runtime_errors_Errors_PARAMETER__C = (((xdc_runtime_Error_Id)640) << 16 | 0);
    You would be searching for 640, and once you find this line, you would know 640 is Error_Id for the error PARAMETER in the module runtime.errors.Errors, and then you can look in the XDCspec file for that module to find out more about that error.
  • Hi Sasha,

    I am not using Error_policyFxn but rater using my own api to log details into my logging tool/framework... I see the following things now when the error is raised

    LINE=124

    ERRORID=276955136

    MODID=41

    Now I went and checked what is 41 corresponds to ie. 0x29 in Hex ... it points to hal_Hwi_Module

    ti_sysbios_hal_Hwi_Module__id ti_sysbios_hal_Hwi_Module__id__C = (xdc_Bits16)0x29;

    now how do I find out which condition is raising it... I  cross checked this file  (C:\ti\bios_6_42_03_35\packages\ti\sysbios\family\c64p) and corresponding line 124 I don't see any Error_raise . wint respect to ErrorID are you able to decode anything with the upper 16 bit data? which is 0x1082

    Regards

    John

  • Error ids are application specific. Try searching for the decimal representation of 0x1082, sometimes we are not consistent with using only hexadecimal numbers.
    The only place where hal.Error raises an error is for stack overflow. Look for E_stackOverflow in your config C file and see if the error code for that matches.