PROCESSOR-SDK-AM335X: How to disable App.Cfg and all the automated code generation??

I've notified the RTOS team. Their feedback will be posted here.

Best Regards,
Yordan

Thank you but:

1. They usually don't.

2. What can I expect as a response to a rant against this "pet project"?  Likely nothing.

This has already resulted in a recommendation for a new project to go with another supplier.  Nine months of dealing with this (how many times during those nine months has support been dropped for existing packages, because the shinny new one is now out?) has been a massive waste.

Chris,

We are sorry to know that you have been having a poor user experience and running into these issues to try and setup up your project. I will try and explain why the cfg file is added to the project and provide some guidance to you interms of writing bare-metal code vs TI RTOS code.

The .cfg file is basically a BIOS configuration file whose intent is to allow users to include different BIOS modules and drivers and automatically link in the right BIOS libraries that are required by the TI RTOS application. the BIOS configuration file is compiled by RTSC tool called XDC tools which converts the .cfg file and the BIOS platform specifications into files that can be interpreted by the compiler and linker. All CCS projects which have been defined as TI RTOS/BIOS projects required .cfg to compiler and XDCtools configuration to pick up platform specific and BIOS specific libraries.

In order to not use .cfg, the project needs to be setup as bare-metal project that only uses a Memory configuration file (.lds/.cmd) and compiler/linker to build the project. In this case the user is responsible for Cache/MMU and vector table configuration for the core.

From your description, it appears that you want to setup a bare-metal project and don`t want to use TI RTOS, is that correct? We don`t have any bare-metal CCS project as bare-metal code in the PDK is compiled using makefiles. However, this can be converted to CCS projects by looking at the compiler settings in the makefile or by looking at the build log from the makefile.

BAre metal examples for AM335x are located at :
pdk_am335x_1_0_7\packages\ti\starterware\examples
pdk_am335x_1_0_7\packages\ti\board\diag

If you indicate, what kind of project you are building, we can provide further guidance. We provide a starting point for setting up bare-metal project:
processors.wiki.ti.com/.../Processor_SDK_RTOS_Examples_and_Demonstrations (No-OS bare metal) and also indicate how headers and includes can be brought in for the drivers:

Regards,
Rahul

Rahul,

I just spend an hour writing a reply.  TI side lost it.  

Rahul,

No. I DO want to use RTOS,  SYS/BIOS, whatever it's called these days. But it fails at every turn when I do something beyond the basic examples. I had a failure rate of about 95%.

I've been fighting this new environment for ten months now.

I know what XDC is supposed to be doing.  I know it digests the CFG file, and spits out a bunch of code.  But it also is hiding all kinds of things from the developer, because TI won't follow INDUSTRY BEST PRACTICES.  I want to include source files, or link to libs, because I am trying to troubleshoot a bunch of things that should work but don't. I don't WANT to be debugging TI demo code in order to figure out how to incorporate it with other PDK components, but that's what this has degenerated into. Tell me what to include, or what to link to.  Nope… can’t do that.  But being a prisoner to XDC and the tools brings nothing but pain and failure.

I needed a TCP/IP Ethernet for a Sitara device.  I started with BBB, and used a demo "blink" project.  Then I used the XGCONF tool to try to add NDK support.  Nothing worked, everything broke with compiler then linker errors.  Hundreds of them.  No doc or support from anywhere I can find.

Suddenly PDK 1.0.7 comes out with an NDK example, only works for CCS 7.2. Thanks, but where was that months ago?? That was FOUR MONTHS AFTER I started this quest. That sure looks like this wasn't ready to be released when it was. Anyway, I bring it in, fix the outright SYNTAX ERRORS in the header files which don’t even compile in C++, and got what I wanted.  That’s the first portion.

Next, I need a USB CDC device. The PDK doesn’t have one. It’s got an MSC, which is so differentiated there is no hope of adapting it to any other device class.  I ask on the forum... the reply?  We haven’t made one yet, maybe later.

But there is one in the older StarterWare.  So I grab it.  But I can’t integrate it into the new CCS.  I reverse the make files, create library projects by hand, and it’s not functioning.  I dig in to debug (yet again, debugging TI example code).  A timer interrupt isn’t firing.  I build just a 5 line sample...  Still doesn’t work.  Yup... more TI demo code that doesn't work.

 Next, I’m going through 10,000’s of pages of docs on the device, where in several places the information appears to be SELF CONTRADICTORY.

 So… I can’t get the old StarterWare incorporated into the new CCS and I have no idea why.  There is no support for what I need in the new PDK because TI just hasn’t “gotten around to it”.

Meantime, I’m debugging TI demo code, and have no idea if it’s correct.  Since so many headers were broken, I have to assume that may be why it’s not working. Or maybe the cryptic linker scripts are incorrect.  But I have to believe these StarterWare packages worked back in the days before all this new stuff came out.  So it's the new PDK, SYSTBIOS, Header, linkers, something in the new packages that is broken.  After all, I found broken things in it already.

I’ve already engaged Eric Wilbur and company, but he’s not a Sitara guy, nor and NDK guy.  He’s really good at explaining how the RTOS works, and using it.  I can’t see paying him again to help me troubleshoot TI DEMO CODE. Or assisting me in figuring out what is wrong with TI headers or linker scripts. Or how to get around XDC.

And at every turn, XDC and the CFG file just interfere with I want to do. I can’t modify a make file because it over writes it.  It’s pulling in settings that I have no idea how to control. There are headers and libs that apparently are getting into the project and I have no idea how.  Because TI didn’t want to follow INDUSTRY BEST PRACTICE in creating the environment.  If some of these scripts are the reason the StarterWare demo won't work, I can't even fix them.  They are being auto-generated by XDC.

On the other hand, I can do “bare metal” coding all day long, from the Valvano books and him examples.  That’s not what I need.  TI is supposed to have an RTOS, NDK, and PDK with USB that works.  Together.  But it's impossible (as far as I can tell) to start with a bare metal project and add RTOS, NDK, PDK pieces to it.  I even posted a question "How to added NDK libs".  The answer?  Use XGCONF...

If I could just include the RTOS code files, or link to the libs without using XDC and the CFG file I would. That MIGHT help me figure out what's wrong.  But I have no idea how to do that.  This environment has so many holes in it, it doesn’t meet my needs, but there is nothing documented on how to get around it.  Just give me doc on the functions (Tasks, Semaphores, StartBios…) that actually tells you WHAT AND WHERE to get the header, and WHAT AND WHERE to find the library to link.  Ever look at the MSDN?  Or even a MAN page??

Why am I here?  Because our company acquired a division that makes an appliance which uses Sitara devices.  And much of the skill set from that project has left.  I decided I would step up, since I have 25+ years in C on Windows, Linux, and a few embedded projects (plus Altera devices, CPLD devices, etc…) The existing projects used the older SDKs and PDKs…  but the new environment apparently doesn’t allow you to use those, or breaks them. And is missing what I need from the newer PDK.

In any other environment, this challenge would have been overcome in a week or so.

 -CSW