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.

TM4C1230D5PM: Stack analysis in CCS

Part Number: TM4C1230D5PM

I am looking for a way to debug stack problems on a TM4C1230D5PM for a GCC project.

When I load the 'stack usage' view, I see:

"The stack usage view supports only TI tool-chain projects. Please select a TI tool-chain to view it's stack usage..."

Are there any options available to me?  Even better, are there any FreeRTOS aware debugging utilities within CCS?

Many thanks,

Dave

  • Hi Dave,

    There are some third party tools that you can try. Some support Eclipse plugins that you can use with CCS. One plugin that I tried is Stateviewer:

    https://www.highintegritysystems.com/tools/stateviewer/

    Thanks

    ki

  • Are there any options available to me?

    For the TI compilers there is the call_graph command utility in the cg_xml. However, call_graph processes DWARF tags which are specific to the TI compiler, and so call_graph can't be used with a GCC project.

    The GNU Linaro ARM gcc-arm-none-eabi-9-2019-q4-major compiler installed with CCS supports the -fstack-usage option:

    Where the output of -fstack-usage doesn't contain any callgraph information, and therefore doesn't easily allow the worst case stack usage to be determined.

    The AdaCore gnat-2021-20210519-arm-elf compiler supports the -fcallgraph-info option:

    I was able to install gnat-2021-20210519-arm-elf, which is based upon GCC 10.3.1, and CCS allowed to use it for a Cortex-R4 based project. https://github.com/simonjwright/stack_usage can process the .ci files and produce an an overall CSV file.

    Since gnat-2021-20210519-arm-elf is intended for Ada, rather than C, development using GCC it does have some limitations compared to the Linaro distribution installed with CCS:

    1. There is no C++ compiler, and no C++ runtime libraries.
    2. There are no *.specs files in the runtime libraries, so have to delete the -specs options in any CCS projects.
    3. There is no crt0 start-up code in the runtime libraries, so have to link with the -nostartfiles option.