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

RTOS/CC1310: Unpicking TI-RTOS from CC1310 and XDC

stomp
Genius 4675 points
Part Number: CC1310
Other Parts Discussed in Thread: SYSBIOS

Tool/software: TI-RTOS

Hi,

Firstly, I get the point of having TI-RTOS and I get XDC, and I understand my topic here may not be "officially supported", which is fine too.

In our products we use TI processors, RM46, RM48, MSP430, MSP430, TMS320 w/ InstaSPIN, we have had great success!.

In every instance we get hold of the base driverlib, bring it up to our company standards, pick out only what we need, perform testing to IEC61508 SIL1 (100% function entries, 100% branches, boundary conditions and MC/DC), perform integration testing, system level and ship the product.

We need to do the same with CC1310, which is heavily bound to TI-RTOS and the XDC tools. Again I get the point of this, but in our instance its simply not possible to ship devices that have untested, or un-testable code in them.

So this leaves us in a position where we have tried to pick out the CC1310 drivers from TI-RTOS (or the other way around depending on your view point).

We are left with a heap of undefined symbols namely: "ti_sysbios_BIOS_clockEnabled__C" (and many others).  We believe these may be defined by the relevant tools for the release.cfg, or even by XDC. Despite a search of our file system, all we can find is some non-trivial references in .oem3 files to these symbols.

Is anyone able to even hint at how something like the code below works:

define ti_sysbios_BIOS_clockEnabled (ti_sysbios_BIOS_clockEnabled__C)
__extern __FAR__ const CT__ti_sysbios_BIOS_clockEnabled ti_sysbios_BIOS_clockEnabled__C;

are those symbols somehow defined as part of the RTOS build process???

Thanks, and again I realize this may be a "non supported" topic, any help would be great.

Stomp!

  • 0
    TI__Mastermind 37985 points
    stomp,
    TI-RTOS requires a configuration step in which XDCtools processes release.cfg and generates various source files. One of them defines the symbols you are asking about. After that, the rest of the app build is just the compiler and the linker processing the generated sources along with the user's sources and some pre-built libraries. If I am reading your post correctly, your requirement is that you build all the sources on your own without any XDCtools involvement. That might be hard to achieve for all the sources, but we can look at the current build flow and see if there are any changes in that build flow that you could make, and have all sources under your control.

    I am not sure which product and which version of it are you using currently, and if you are using CCS, but the most recent TI-RTOS release is available as a part of SimpleLink SDK - www.ti.com/.../SIMPLELINK-CC13X0-SDK, which is compatible with CCS 7.1.0. In that product we do have some level of separation between XDCtools-based configurations and the apps that use these configurations.
    You can import examples from Resource Explorer, for example you can follow the path examples/rtos/<your board>/demos/portable/ti/rtos/ccs and import the example 'portable'. The example consists of two different projects, one with release.cfg, I'll call it the configuration project, and another with C app sources which I'll call the app project.

    The app project references the configuration project through various compiler and linker command line options:
    - cmd_file=<ccs workspace>/tirtos_builds_CC1310_LAUNCHXL_release_ccs/Debug/configPkg/compiler.opt
    This file points to necessary defines, includes and various header files.
    - <CCS workspace>/tirtos_builds_CC1310_LAUNCHXL_release_ccs/Debug/configPkg/linker.cmd
    This file links in some libraries and object files that are built in the configuration project out of the sources in that same project. That part of the build is controlled by a couple of gmake makefiles, and it shouldn't be difficult to replicate that part in your own environment. Then, there are additional libraries coming from TI-RTOS product, which are pre-built, but the sources are available.

    Can you take a look at that example and these two files I mentioned above and let me know if I am answering your question? I can go into more details if it seems that there is a chance to rearrange this build process according to your requirements.
  • 0 in reply to Sasha Slijepcevic
    Genius 4675 points
    Hi Sasha,

    Firstly, thanks for your time. I know this stuff is technically not supported!.

    To answer your questions, yes the first thing we need to do is put all the files for the CC1310, TI-RTOS and XDC under our own source control and build the project in a stand alone format, before removing the XDC and TI-RTOS parts.

    As for your help. The compiler.opt and linker.cmd files were exactly what we needed, and I'm very thankful for this information as now we have achieved our primary mission and our project is now built stand alone.

    Best Regards and thanks again.

    Stomp!