• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 54 subscribers
  • Views 609 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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/SIMPLELINK-CC13X2-26X2-SDK: Long time required to start a debug session.

Adam Kozlowski
Expert 1805 points

Part Number: SIMPLELINK-CC13X2-26X2-SDK
Other Parts Discussed in Thread: UNIFLASH

Tool/software: Code Composer Studio

Hi,

Background
I use CCS 10.1 along with Launchpad-CC13x2 and SDK 4.20.
I work on the custom c++ project that is built on top of the "hello" template. I use GNU 9.2.1 toolchain.
So far the program has
.text - 171849       
.data - 15108
.bss - 34828
There is still plenty of room to use. We didn't even approach half of the CC13x2 capabilities...

Problem definition
Recently, I've discovered that the time necessary to launch the debug session has reached an unacceptable boundary.

Results
When I use the CCS automatic chain, the time necessary to start the debug session exceeds 4.5 min.

Fortunately, I can speed up this process a bit by using UniFlash and manually attaching a debugger.
Flashing (uniflash) - 12s
Attaching debugger - 2-5s (connect target/connect core)
Loading debug symbols - 1min 50s

Better, but still beyond imagination... Moreover, this approach is not so convenient.

Loading symbols is extremely time-consuming. The .out file has 24MB.
I've thought about splitting .out into executable and separate .debug information but I have no idea if it's a case.
Maybe, we can somehow prepare this file to be "better" consumed by the IDE.

Questions:
Assuming I use the second approach, how can I speed up the loading symbols process?

How can I speed-up the automatic CCS debug chain?

What can I do (prepare) for you to let you solve this problem?

Remarks
I believe the programs are getting bigger mainly due to the device capabilities so this problem can be essential to solve.

----------

In the meantime, I've checked splitting the .out file into separate executable file and debug info.
The sequence was as follows:
arm-none-eabi-objcopy --only-keep-debug $@ $@.debug
arm-none-eabi-objcopy --strip-unneeded $@
arm-none-eabi-objcopy --add-gnu-debuglink=$@.debug $@

Unfortunately, even when I load symbols from the separate .debug file, it doesn't speed up the process.

----------

Regards,

Adam

  • 0
    Expert 1805 points

    Hi,

    In the meantime, I've checked splitting the .out file into separate executable file and debug info.
    The sequence was as follows:
    arm-none-eabi-objcopy --only-keep-debug $@ $@.debug
    arm-none-eabi-objcopy --strip-unneeded $@
    arm-none-eabi-objcopy --add-gnu-debuglink=$@.debug $@

    Unfortunately, even when I load symbols from the separate .debug file, it doesn't speed up the process.

    Regards,
    Adam

  • 0 in reply to Adam Kozlowski
    TI__Guru**** 481131 points

    Hi Adam,

    You issue sounds similar to the one reported by Robert in the below thread:

    https://e2e.ti.com/support/tools/ccs/f/81/t/929579

    If you can provide your out file like I have requested Robert, that would be great.

    Thanks

    ki

  • 0 in reply to Ki
    Expert 1805 points

    Hi Ki,

    Ki said:
    You issue sounds similar to the one reported by Robert in the below thread:

    Indeed, it is.
    We work together. It's the same project.
    I've decided to split it up, and extract the part concerning only the symbols loading process to the new thread.

    The Robert's thread is focused on the whole debugging process (what I call an automatic chain debugging), including flashing, GELs, loading symbols, etc..
    My ticket is mainly devoted to the symbols loading part (manual debugging).

    Ki said:
    If you can provide your out file like I have requested Robert, that would be great.

    We can try to prepare some minimal, reproducible example, but really I don't know if it is possible.

    At this stage, we have some conclusions (clues):

    • the long time necessary to load symbols is associated with the file size (our .out file has more than 25MB) or some computational difficulties during file parsing.
    • our project heavily uses templates and metaprogramming, thus our "linkage_names" in DWARF are really long, see attached.

    Please share these conclusions with people working on the CCS module used to load symbols. I believe, it can help to solve the problem.

    Fullscreen debug_ti_1.txt Download 
     <3><2950ff>: Abbrev Number: 38 (DW_TAG_subprogram)
    <295100>   DW_AT_external    : 1
    <295101>   DW_AT_name        : (indirect string, offset: 0x55f359): operator=
    <295105>   DW_AT_decl_file   : 85
    <295106>   DW_AT_decl_line   : 224
    <295107>   DW_AT_decl_column : 20
    <295108>   DW_AT_MIPS_linkage_name: (indirect string, offset: 0x35bfe4): _ZNSt11_Tuple_implILj25EJN3iwn15TypeABCDIaLa0ELNS0_17SomeClassificationE1ELNS0_16SomeAccessibilityE1ENS0_18DefaultTypeValidateIaEEEENS1_ItLt15360ELS2_1ELS3_1ENS4_ItEEEENS0_15TypeABCDINS0_10TypeABCDEL_ZNS0_18ABCD_TypesABCDDefEELS2_3ELS3_1ENS4_ABCD_EEJEEENS9_INS0_14SomeAlertEL_ZNS0_22ABCD_SomeAlertDefEELS2_3ELS3_1ENS4_ISD_EEJEEENS9_INS0_13SmoothFactorsEL_ZNS0_21ABCD_SmoothFactorsDefEELS2_1ELS3_1ENS4_ISG_EEJEEENS9_INS0_13QueueABCDEL_ZNS0_21ABCD_QueueDEFGDefEELS2_1ELS3_1ENS4_ISJ_EEJEEENS0_10ArrayABCDE1DINS9_INS0_2ChEL_ZNS0_10DEFG_SomeDefEELS2_1ELS3_1ENS4_ISN_EEJEEELt10EEENS9_INS0_17TypeABCDEFEL_ZNS0_12ABCD_SomeDefEELS2_1ELS3_0ENS4_ISR_EEJPSQ_EEENSM_INS9_INS0_10SomeTemplateEL_ZNS0_18DEFG_SomeTemplateDefEELS2_1ELS3_1ENS4_ISV_EEJEEELt8EEENS9_ISR_L_ZNS0_12ABCD_SomeDefEELS2_1ELS3_0ESS_JPSY_EEENSM_INS9_INS0_8TypeABCDEL_ZNS0_16ABCD_SomeDefEELS2_1ELS3_1ENS4_IS11_EEJEEELt2EEENSM_INS9_INS0_17SomeDiagnosticResetEL_ZNS0_26ABCDE_SomeDiagResetDefEELS2_1ELS3_1ENS4_IS15_EEJEEELt39EEENS9_ISR_L_ZNS0_12ABCD_SomeDefEELS2_1ELS3_0ESS_JPS14_EEENSM_INS9_INS0_10TypeABCDEL_ZNS0_18ABCD_SomeTypeABCDDefEELS2_3ELS3_1ENS4_IS1B_EEJEEELt3EEENSM_INS9_INS0_14TypeABCDIdleEL_ZNS0_22ABCD_TypeABCDEFIdleDefEELS2_3ELS3_1ENS4_IS1F_EEJEEELt3EEENS9_ISR_L_ZNS0_12ABCD_SomeDefEELS2_1ELS3_0ESS_JPS1E_EEENSM_INS9_INS0_5TypeABCDEL_ZNS0_13ABCD_SomeDefEELS2_1ELS3_1ENS4_IS1L_EEJEEELt2EEENS9_ISR_L_ZNS0_12ABCD_SomeDefEELS2_1ELS3_0ESS_JPS1O_EEENSM_INS9_INS0_4TypeABCDEL_ZNS0_12ABCD_SomeDefEELS2_1ELS3_1ENS4_IS1R_EEJEEELt9EEENS9_ISR_L_ZNS0_12ABCD_SomeDefEELS2_1ELS3_0ESS_JPS1U_EEENSM_INS9_INS0_5TypeABCDEL_ZNS0_13ABCD_SomeDefEELS2_1ELS3_1ENS4_IS1X_EEJEEELt3EEENS9_ISR_L_ZNS0_12ABCD_SomeDefEELS2_1ELS3_0ESS_JPS20_EEENSM_INS9_INS0_12TypeABCDDiagEL_ZNS0_20ABCD_TypeABCDDiagDefEELS2_3ELS3_0ENS4_IS23_EEJEEELt39EEENS9_ISR_L_ZNS0_12ABCD_SomeDefEELS2_1ELS3_0ESS_JPS26_EEENSM_INS9_INS0_11TypeABCDDiagEL_ZNS0_19ABCD_TypeABCDDiagDefEELS2_3ELS3_0ENS4_IS29_EEJEEELt15EEENS9_INS0_11SomePolicyEL_ZNS0_19ABCD_SomePolicyDefEELS2_1ELS3_1ENS4_IS2D_EEJEEENS1_ItLt0ELS2_1ELS3_1ES7_EEEEaSERKS2H_
    <29510c>   DW_AT_type        : <0x3022b3>
    <295110>   DW_AT_declaration : 1
    <295111>   DW_AT_deleted     : 1
    <295112>   DW_AT_object_pointer: <0x29511a>
    <295116>   DW_AT_sibling     : <0x295126>

    Regards,

    Adam

  • 0 in reply to Adam Kozlowski
    Expert 1805 points

    Some fresh information.

    I tried to compress the debug section using

    arm-none-eabi-objcopy --compress-debug-sections Debug\debugtest_hello.out

    Results:

    • The .out file is about 3 times smaller (9MB)
    • The loading symbols process is fast (comparable to the time of hello template)
    • There are no messages with errors.
    • Unfortunately, after loading symbols, the IDE doesn't see the symbols loaded.

    Regards,

    Adam