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.

CCS/TMDSRM48HDK: Debug Call Stack - "next frame is identical to an existing frame"

Part Number: TMDSRM48HDK


Tool/software: Code Composer Studio

Hello,

I have some problems when debbuging with Code Composer Studio (6.1.2.00015).

I’m trying to get the functions call stack but there is only the previous frame repeated or the message « next frame is identical to an existing frame ».

I’m working with a RM48HDK (RM48L952ZWT rev E) board using a RTOS (µCOS-III) and I’m debbuging with a Spectrum Digital XDS200 USB debug probe. The host OS is Windows 7 Professional 64bits Service Pack 1.

These are my project settings :

Compiler :

-mv7R4 --code_state=32 --float_support=VFPv3D16 --abi=eabi -me --include_path="C:/ti/ccsv6/tools/compiler/ti-cgt-arm_5.2.7/include" --display_error_number --diag_warning=225 --diag_wrap=off --enum_type=packed --no_stm

Linker :

-mv7R4 --code_state=32 --float_support=VFPv3D16 --abi=eabi -me -g --display_error_number --diag_warning=225 --diag_wrap=off --enum_type=packed -z -m"MUX.map" --stack_size=0x800 --heap_size=0x800 -i"C:/ti/ccsv6/tools/compiler/ti-cgt-arm_5.2.7/lib" -i"C:/ti/ccsv6/tools/compiler/ti-cgt-arm_5.2.7/include" --reread_libs --warn_sections --diag_wrap=off --display_error_number --xml_link_info="MUX_linkInfo.xml" --rom_model

Is there a way to see the complete call stack ? Is it a bug or do I need to put some parameters ?

Thanks,

Bastien

  • Hello Bastien,
    Can you provide a reproducible test case (the simpler the better)? The executable *.out is the main thing.

    Thanks
    ki
  • Hello,

    Here is my .out file:

    2262.MUX.zip

    I'm creating a periodic task which toggles leds. The toggle function is called through 3 different functions:

    void function3(void)
    {
        BSP_LED_Toggle(2);
    }
    void function2(void)
    {
        function3();
    }
    void function1(void)
    {
        function2();
    }

    static void AppTaskStart (void *p_arg)
    {
        OS_ERR err;

        /* Initialize the Tick interrupt */
        OS_BSP_TickInit(OSCfg_TickRate_Hz);

        BSP_LED_Off(0);
        while (1)
        {
            BSP_LED_Toggle(1);
            function1();
            OSTimeDlyHMSM((CPU_INT16U) 0,
                          (CPU_INT16U) 0,
                          (CPU_INT16U) 0,
                          (CPU_INT32U) 500, // 500ms
                          (OS_OPT )OS_OPT_TIME_HMSM_STRICT,
                          (OS_ERR *)&err);

            if (err != OS_ERR_NONE)
            {
                BSP_LED_On(6);
            }
        }
    }


    Here is the result when i place a breakpoint in function3:

    Thanks,

    Bastien

  • Hi Bastein,

    The error msg on the call stack is a bit misleading.

    If you were running CCS v7, you will see this.

    I check the debug info in the object file. The compiler did not generate any information on how to unwind the callstack beyond the second frame.

    I will file a compiler bug.

    -Raymond

  • Hello,

    So it's a compiler bug? I must wait for an update?

    Thanks for your help,

    Bastien

  • Hi,

    We are going to need a reproducible test case that we can compile.  Also, this forum post will be moved to the compiler forum.

    If a bug is found, the branch you are using, ARM CGT v5.2.x, will not be updated with a patch because it is reactive.  Only active branches will be patched with the fix.  In the meantime, you can try compiling your code with a later branch to see if the problem still persists.  

    Thanks,

    Anna Youssefi

    Compiler Support Team

  • I've put together the test case and attached it to the bug, which is CODEGEN-2257
  • It's the flag --no_stm that is causing the problem. It mistakenly discards the relevant information for the function prolog. Make sure the device you are using does suffer from the bug that --no_stm works around. If it does not have that bug, don't use --no_stm