• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 98 subscribers
  • Views 390 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.

Strange build behavior of my SYSBIOS project

Allen Li30
Prodigy 90 points
Other Parts Discussed in Thread: SYSBIOS

Hi Talents,

I am facing a very strange build problem with my SYSBIOS project. I didn't build it inside CCS, instead, in a private build system. But all tools comes from TI officially.

CGTools:v7.4.2

SYSBIOS:6_37_02_27

xdctools:3_25_05_94

The problem is after the build, no error is reported during compile and link, but some function/label from SYSBIOS were missed according to the comparison with a correct build, for example:

The right side is correctly built, while left side shows some label is missed. So the result is when I entered the BIOS api, the DSP is blocked/crashed.

The two sides use the same CFG file.

Thanks,

Allen

  • 0
    Prodigy 90 points

    Sorry, screenshot missed. Please see below:

  • 0 in reply to Allen Li30
    TI__Mastermind 30830 points
    Allen,

    What device/target is this?

    It seems you may be linking with the wrong boot files. The BIOS build process requires you to use the boot file provided by the xdc target's runtime support library rather than the CG tools' boot file.

    I'll probably need more details about your private build system. However, the question that comes immediately to mind is what is different in the build flow between the working build and the non-working build?

    Can you show the output from your compile and link steps?

    Alan
  • 0 in reply to Alan DeMars
    Prodigy 90 points

    Hi Alan,

    We are performing development on Jacinto5 platform, C674x inside.

    I have attached the build logs and memory.map of both working and non-working build.

    The B271 build is working whilc B273 build is not.

    According to the map comparison, as you said, most of missing parts are included in BIOS.obj of sysbios.a674 library.

    Thanks,

    Allen

    5722.build.zip

  • 0 in reply to Allen Li30
    TI__Mastermind 30830 points
    As I suspected, the bad version's c_int00 is coming from the rts6740.lib library:

    .text:_c_int00
    * 0 8757e000 00000080
    8757e000 00000080 rts6740.lib : boot.obj (.text:_c_int00)

    And the good version's c_int00 is coming from the xdc target's boot.a674 library:

    .text:_c_int00
    * 0 87580000 000000c0
    87580000 000000c0 boot.a674 : boot.o674 (.text:_c_int00)

    I couldn't really tell from the build logs, but you need to make sure the rts6740.lib library appears AFTER the "linker.cmd" file in the application's final link command. This will ensure that the xdc runtime's version of c_int00 (that references all the missing APIs) gets pulled in rather than the TI CGTool's version.

    Alan
  • 0 in reply to Alan DeMars
    Prodigy 90 points
    Hi Alan,

    Your suspection is correct.
    The linker tends to sequence the linker inputs(.lib,.obj,.a) randomly? So in our build system, we have defined the priority of each input.
    Here I use libc.a as one input which contains the symbols(c_int00) from rts6740.lib, so I try to mandatory set the priority of libc.a to low to make it present at the end of linker command line. Then the problem is solved!!
    Great thanks to your clue.

    Allen