CCS/PROCESSOR-SDK-AM335X: Yet ANOTHER out of the box FAILURE

Hi Chris,

I see this in the PRSDK docs: http://processors.wiki.ti.com/index.php/SYS/BIOS_with_GCC_(CortexA)#What_do_I_need_to_do_to_make_the_C_runtime_library_re-entrant_when_building_SYS.2FBIOS_applications_for_Cortex-A_GNU_targets.C2.A0.3F

I also see this E2E thread: https://e2e.ti.com/support/processors/f/791/t/640006?RTOS-SYSBIOS-GNU-linker-error-with-SYSBIOS-v06-52-00-12

I notice SYSBIOS 6.83.00.18 has a dependency on XDCTools 3.61.03. However, I can't find a public location for this XDCTools version: http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/rtsc/index.html

The SYSBIOS release just prior to 6.83.00.18 is 6.82.01.19. This version is available for download at the above link, and the associated XDCTools version 3.61.0.16 is located in the CCS 10 installation.

I tried creating the SYSBIOS "Typical" example using SYSBIOS 6.82.01.19 & XDCTools 3.61.0.16. However, I see the same build problem:

C:/ti/bios_6_82_01_19/packages/ti/sysbios/rts/gnu/ReentSupport.c:84: undefined reference to `ti_sysbios_rts_gnu_ReentSupport_checkIfCorrectLibrary'

I followed the instructions in the above docs / e2e threads, but I still see the same build error. Checking the SYSBIOS installation, I notice there isn't a folder <BIOS>\packages\gnu\targets\arm\libs\install-native\arm-none-eabi\lib\hard. To me this suggests the required library isn't included in the installation package.

I was able to get the SYSBIOS "Typical" example building in CCS 10 using the SYSBIOS & XDCTools versions packaged with PRSDK 6.3. I recommend you use those versions since they've been tested as part of the PRSDK release.

Regards,
Frank

Okay, I installed the packages as described, since the page was not discovered on any search engines, only pages that show the latest versions of these packages.

The "Out of Box" failures continue:

Well, I don't have a newer version of Java.  Was that a prerequisite?  Should it have been explained somewhere?  Should the package installer have detected it and aborted or prompted the user?

Oddly enough, it will actually build a project.  But the XGCONG window won't open.

No matter what "console" I open, there is no "XDCTOOLS_JAVA_HOME" defined anywhere I can find.  So this is an environmental variable that I do not have any control over.  I can find no setting anywhere in the IDE that controls what version of Java it uses.

(CCS7 now only "kind-of" works.  It kept giving me blank screens...  I was about to complain about CCS 10 damaging some of those projects, until I made the miraculous discovery that it will show the screen if you re-size the window (force a repaint) )

Am I supposed to go directly to Oracle and install their Java, complete with all the spyware, adverts, and browser add-ons?   Or should this use the existing version  (jre6) ?  Or does TI have a recommended/customized version?

Frank,

Happy Monday... turn it on and it works.  The XCONF graphic screen now works, and I did NOT install any new JAVA, or so anything else.  It just  started working on it's own.

Very annoying...

Also, I am way past the installing the packages step.

What I cannot understand is:

How does it add the "C:\ti\bios_6_46_05_55" path when the project has NO SYSBIOS product selected??

Well, your explanation of 

• Select Window -> Preferences
• Select Code Composer Studio -> Build -> Variables
• Click "Show System variables"
• Double-click on "BIOS_CG_ROOT"

And although the list in the dialog box says "ECLPISE_DYNAMIC_VARIABLE" when I double click it, it shows me the actual path.

Seems to indicate that CCS is using this as a default search path all the time, regardless (unless you take the step of adding SYSBIOS from a different package which overrides it).

Now... yet another annoyance!!!!  Why is this compiling *.S files when I tell it to "build selected file" on a "c" file?   

And why does it do that even if I select the "S" file and mark it as "exclude from build" ??

Chris,

Christopher Weber said:

Now... yet another annoyance!!!!  Why is this compiling *.S files when I tell it to "build selected file" on a "c" file?   

And why does it do that even if I select the "S" file and mark it as "exclude from build" ??

I'm not sure. Can you please open a new thread for this topic?

Thanks and regards,
Frank

Frank,

I did.  Here:

e2e.ti.com/.../956849

Which has a link to a screen capture showing that I can tell it to ignore the first S file and it does.

But if I tell it to ignore the SECOND S file, it doesn't.

AND... (someone put an # include in there - wasn't me) the assembler was trying to compile XDC "C" code and generated 1000's of lines or errors... that is expected.   

BUT that all scrolled off the window.  So I spend days just trying to figure out WHERE THESE ERRORS WERE COMING FROM.  Because the errors are all attributed to XDC source files.

If the window held enough, or just logged it to a file I could open after the fact, I could have seen the original command line and not spend days trying to figure out which source file was the cause.

Hi Chris,

Christopher Weber said:

If the window held enough, or just logged it to a file I could open after the fact, I could have seen the original command line and not spend days trying to figure out which source file was the cause.

I don't think there's a way to redirect the build output to a file. I only see a "copy" and "scroll lock" feature. This is discussed in this e2e thread: https://e2e.ti.com/support/tools/ccs/f/81/t/87023

One possible workaround is build your CCS project from the command-line, and redirect the build output to a file. Please check this: http://software-dl.ti.com/ccs/esd/documents/ccs_projects-command-line.html

Regards,
Frank

Frank,

Another one...  (Do I open question?)

As I dig, and look at the GNU compiler, I guess TI has abandoned the "SYS_BIOS_PATH" in this thing, and now there is a ${COM_TI_BIOS_INCLUDE_PATH}.

Guess what...? It's empty. not just "not populated yet" It's actually EMPTY. And not defined anywhere in the preference you described.

Given this set of includes:

${COM_TI_BIOS_INCLUDE_PATH}
${PROJECT_ROOT}
${CG_TOOL_INCLUDE_PATH}
${PROJECT_ROOT}/ti

(yes, I have a "TI" folder in the project) My build command is this:

C:/ti/gcc-arm-none-eabi-7-2018-q2-update/bin/arm-none-eabi-gcc-7.3.1.exe" 
-c 
-mcpu=cortex-a8 
-march=armv7-a 
-mtune=cortex-a8 
-marm 
-mfloat-abi=hard 
-I"C:/Source/projects/DnsTest" 
-I"C:/ti/gcc-arm-none-eabi-7-2018-q2-update/arm-none-eabi/include" 
-I"C:/Source/projects/DnsTest/ti" 

This is truncated from the full command line, but notice there are 4 directories listed, but the command line has three. And the first one: ${COM_TI_BIOS_INCLUDE_PATH} is not even listed.

Next I created a quick test project, and the includes are this:

${COM_TI_BIOS_INCLUDE_PATH}
${PROJECT_ROOT}
${xdc_find:gnu/targets/arm/libs/install-native/arm-none-eabi/include/newlib-nano:${ProjName}}
${xdc_find:ti/posix/gcc:${ProjName}}
${CG_TOOL_INCLUDE_PATH}

What the heck is that {xdc_find... ??

Obviously it's some search that is invoked, but what? Is it documented someplace? And why does it have the project name appended to it?

Any idea what it is?

Chester...  WOW.

That'll be useful.    You're right, another non-obvious, hidden behavior.

I've got a "global-build.log" of 38,000 line!  I wonder when it is purged?

Hi Chris,

Christopher Weber said:

Another one...  (Do I open question?)

Yes, I would open a separate thread for these questions. This is so:

1. the Q&A can be more easily located in the future by other people with a similar problem
2. the right "expert" is assigned to the thread.

I'll close this thread for now.

Regards,
Frank

Chester,

Thanks much, very useful info.

Regards,
Frank