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.

CCS/LAUNCHXL-CC1310: FreeRTOS Port

Part Number: LAUNCHXL-CC1310
Other Parts Discussed in Thread: CC1310, , CC1021

Tool/software: Code Composer Studio

Dear TI,

I need some help getting FreeRTOS to run on this device.   I found a CCS project and port that works for the CC3220 at http://www.freertos.org/TI_CC3220_SimpleLink_FreeRTOS_Demo.html.  They say that the port included in that project should work on the M3 Core of the CC1310.  This is my first experience with CCS so I don't know it that well.  I've been able to run example projects on the CCS/LAUNCHXL-CC1310 like the first Project 0 that transmits or receives data, but I wasn't able to create a new simple project from scratch for the CC1310 - ran into the error Reset_ISR is not defined.  I think I need to start with some basic demo project and somehow bring in the FreeRTOS port from that other CC3220 project.  Any suggestions on how to do this would be greatly appreciated.  Thanks, Brett

  • Hi,

    starting from SimpleLink CC13x0 SDK 1.40, this is theoretically possible although it requires decent effort and some coding experience.

    You need to implement the Driver Porting Layer for FreeRTOS. An implementation for FreeRTOS is available in the latest SimpleLink SDKs for CC32xx and MSP432. Have a look into <SDK_INSTALL_DIR/kernel/freertos/>. You will need to port all files in the subfolders dpl, posix and startup. A lot of content can be copy-pasted though. Special care must be taken when porting the power module and the HWI module. For those, you should better take the content of the CC13x0 no-RTOS DPL implementation. Also note that the CC13x0 drivers uses Software Interrupts (SWI) which are only really implemented in the TI-RTOS kernel. The no-RTOS DPL for CC13x0 provides a light-weight implementation based on a hardware-interrupt. This has to be ported as well.

    I will not be able to provide you with step-by-step instructions, but might be able to answer specific questions. Good luck.

  • Thanks Richard, I think I have a better picture now of how it would be done, and how all these software layers go together. That's more involved then I would have hoped. The SimpleLink User's Guide should probably be updated in the FreeRTOS section to indicate that the 13x0 SDK 1.40 does not support FreeRTOS without additional porting . It's not clear right now that I get what I want out of the port you describe with the compromises that need to be made - I need to run FreeRTOS in a tickless mode and I'm not sure if there will be any significant performance degradation for my app using the light implementation you described - I'll have to study that more before committing. The port for the CC32XX looks complete. Are there any plans to do a complete FreeRTOS port for the 13x0 ?

    Actually, I have another thought that may be kind of crazy, but is it possible to implement bare metal code that runs on that part that can interface with the radio?   I'm not sure I need the SimpleLink SDK, but maybe I'm missing something.   FreeRTOS has a port that runs on ARM M3 Core.  Could I dump the SDK altogether and just use that port?  What am I missing?
     
    Thanks,
    Brett

  • Hi,

    Brett Preston said:
    The SimpleLink User's Guide should probably be updated in the FreeRTOS section to indicate that the 13x0 SDK 1.40 does not support FreeRTOS without additional porting .

    Where do you think, would be a good place?

    Brett Preston said:
    Are there any plans to do a complete FreeRTOS port for the 13x0 ?

    No, not that I know of. Most customers that wanted an alternative to TI-RTOS wanted a simpler solution and didn't need an "RTOS" at all. That's why we created the "No-RTOS" DPL implementation. The No-RTOS DPL is not really bare-metal, but rather a super-simple RTOS with only a single task using a single RAM stack.

    Brett Preston said:
    It's not clear right now that I get what I want out of the port you describe with the compromises that need to be made - I need to run FreeRTOS in a tickless mode and I'm not sure if there will be any significant performance degradation for my app using the light implementation you described - I'll have to study that more before committing.

    That is not an issue. The Clock/Timer implementation in the No-RTOS DPL (and also in TI-RTOS DPL) is tickless as well. We call that "dynamic tick mode". I don't see any limitation, but you should have studied the No-RTOS DPL implementation for CC1310 and the FreeRTOS DPL implementation for CC32xx before getting your hands dirty. I don't see a performance limitation on FreeRTOS. The question is more, whether you want to invest the effort. The DPL is not an official API and it might (even though unlikely given the effort TI has invested into this) change a lot from release to release.

    Brett Preston said:
    Actually, I have another thought that may be kind of crazy, but is it possible to implement bare metal code that runs on that part that can interface with the radio? 

    Don't do that! Power management on the CC13xx is very complex and we are trying to squeeze the optimum power consumption out in our high-level drivers. Use the drivers whenever possible or implement your own ones when you need some special functionality.

    Brett Preston said:
    Could I dump the SDK altogether and just use that port?  What am I missing?

    Maybe you get something that runs, but power management is treated very different on every M3 device. And you would need peripherals drivers. I don't recommend that.

  • Hi Richard,

    Thanks for your answers. We have a proprietary radio protocol that includes periodic transmissions, fixed size packets, and frequency hopping. Our application will need to listen to older TI transmitters like the CC1021. The functionality that was previously in a host controller and the CC1021 will now move to the CC1310. I'm just searching for the right implementation approach. It sounds like we should build on top of the SDK. I don't want to reinvent the wheel so if it can save time and meet our requirements great.

    Some small doc issues to consider -

    It would be nice if on this page there were links to download the SDK's for each device. I did quite a bit of clicking around trying to find out where I could download them. Also, for some reason, the 1310 download file doesn't have a ".exe" extension. I ended up putting it in myself to get the installer to run. The 3220 file had the extension.

    www.ti.com/.../simplelink-mcu-platform.page


    It wasn't clear to me by looking at the page below that you actually have an SDK for each supported device. I would suggest making that clear in the opening paragraph. You do say that not all SDK's support FreeRTOS in the Kernel section. I would list the devices that don't support FreeRTOS out of the box here and in the FreeRTOS section.

    dev.ti.com/.../Users_Guide.html

    Hope this helps.

    Thanks,
    Brett
  • Hi,
    thanks for your feedback. I have forwarded the first paragraph to marketing and the second one to the SDK team. But why did the downloaded file not have an .exe extension? I double-checked and it works as expected.

  • Hi Richard,

    I must have dropped the .exe when I did a SaveAs.  Sorry about that.  I have a question about the clock object that has been sitting unanswered for over a week.  It would be great if you could get an expert to take a look.  The link is below. 

    The application is coming together using your SDK and TI-RTOS, but it would be great if I could occasionally adjust the phase of a periodic clock.

    e2e.ti.com/.../618487 phase of periodic clock

    Thanks!

    Brett