• State TI Thinks Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 2 answers
  • Subscribers 99 subscribers
  • Views 962 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.

Original question:

RTOS/AM6548: CCS8.2 cannot debug the AM6 Temp project?

RTOS/AM6548: Target not run as the symbol "main" is not defined

Thomas Dorsch
Expert 2601 points
Part Number: AM6548

Tool/software: TI-RTOS

Hello,

I can reproduce the issue described in (Target not run as the symbol "main" is not defined)

with CCS  8.2.0.00007 as well.

Is there any fix in the pipeline for the next update, or a workaround?

Best regards,

Thomas

  • 0
    TI__Guru** 116170 points

    Thomas,

    Yes, this is currently a known issue with A53 binaries built with GCC compiler that is being looked at. . Please confirm that you are also seeing this on the A53 core. For now, R5F related code built with TI ARM compiler should not be showing this behavior in CCS.

    The bug ID for the same is PRSDK-4654. you can check for this in the Release notes to track resolution


    Regards,
    Rahul

  • 0 in reply to Rahul Prabhu
    Expert 2601 points
    Hi Rahul,

    yes, I confirm. I also see this issue on the A53 core.

    I would like to add some additional information which may help you to track the error down:
    When I load the program, and start it (even if CCS does not find the main symbol) i get immediatly UART output
    "Board Init complete".

    Now the program seems to stuck for 9-10 minutes before it "resumes" with UART output "Board Init complete"...
    This is reproducable!

    If i understand you correctly, there is a issue with the gcc toolchain? So the binary output of this is not trustfull?

    When you need additional information, please let me know!

    Best regards,
    Thomas
  • 0 in reply to Thomas Dorsch
    TI__Guru*** 125430 points

    Thomas,

    I think we have it figured out.  From what I understand, there's an issue in GCC where things get corrupted when generating a build-id but then later declaring it as NOLOAD.

    The simplest workaround (in my opinion) is to just disable the build-id feature altogether.

    • Go to CCS project properties
    • Go to Build -> GNU Linker -> Miscellaneous
    • Click '+' to add a miscellaneous flag.
    • Enter -Wl,--build-id=none as your flag.

    Here's a screenshot:

    I hope this hasn't been causing you too much grief.  Sorry to keep you waiting so long for a fix.  It wasn't easy to figure out!!!

    FYI, the alternative fix is to remove the NOLOAD in linker.lds for the template app:

    - .note.gnu.build-id (NOLOAD) : { *(.note.*) }
    + .note.gnu.build-id : { *(.note.*) }

    My own preference is to fix this at the command line, though if you had any inputs on either of these as being preferable to the other, I'd be interested to get your perspective.

    Best regards,
    Brad

  • 0 in reply to Brad Griffis
    TI__Guru*** 125430 points
    PS. This took a lot of collaboration between TI's SDK team, CCS team, as well as the Linaro toolchain team to get to the root. Thanks to all that were involved in figuring this out.