• Resolved

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

    -----------------------------------

    Did you read the CCS Forum Guidelines & FAQ? If not, PLEASE read it. If you haven't read it in awhile, please read it again to see if any updates were made.

    Having CCS problems? Check out the CCS Troubleshooting Guide

    Looking for CCS Training? Check out the CCS Training Site

    Curious about the status of a bug and know the tracking ID? Track it via the public bug tracking portal

  • In reply to Ki-Soo Lee:

    Hello,

    Here is my .out file:

    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

  • In reply to Bastien Ondel:

    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

  • In reply to Raymond Pang:

    Hello,

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

    Thanks for your help,

    Bastien

  • In reply to Bastien Ondel:

    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

  • In reply to Anna Youssefi:

    I've put together the test case and attached it to the bug, which is CODEGEN-2257
  • In reply to Archaeologist:

    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