CC1350: Writing non-RTOS-based software for CC1350

Hi Pawel,
I think the biggest hurdle that you will face is the Radio module that uses a mailbox system. In the 15.4 stack, TI-RTOS uses ICall to interface with the radio, and the RF examples uses libraries so you don't actually have access to the source to try to implement those functions.
One of the advantages of using TI-RTOS is that most functions are pre-programmed into the ROM so it doesn't use any flash space. It only needs to be linked during compilation.
Maybe someone knows more about this than me, but I tried doing a similar procedure with the CC2650 (same device, different radio) and I gave up after a while.
If you don't need the RF module, than I would suggest using another device.
Regards,
Michel

Thank you Michel,

Yes, there are obvious arguments against  using CC1350 without RTOS, because it clearly looks like TI doesn't want me to do that. The radio, in fact, appears to be well documented in the manual, but the ROM is another discouraging issue (if I don't use it, then it becomes an unnecessary luggage, even if there is a way around it). So I am inclined to give it up and consider another device. The radio is what makes CC1350 attractive for the project, but maybe less so than it seems at first sight, especially when there is a lot of reverse engineering to do with uncertain outcome and there exist other options.

Cheers!

Pawel

Pawel,

FYI - We are working on a non-OS kernel replacement, allowing you to replace the TI RTOS kernel and still use e.g. the power and RF drivers.
Once this is in place, it should be significantly simpler to port your application over to another RTOS as well if needed.

If you have concrete examples of missing documentation or use of undocumented registers, please list them and we will work to add those into the technical reference manual and corresponding header files.

Regards,
Svend

Hello Jonas,

Thanks. Right. So my question can now be rephrased this way:

I see that TIRTOS doesn't really use cc13xxware (which comes with it), but has its own version (tidrivers_cc13xx_cc26xx), right? Will I be OK when I take just cc13xxware and forget about the rest of the set?

The reason I'm asking is that I see things in tidrivers that are not mentioned in cc13xxware (and not documented in swcu117f). Let me pick the first such item I can see: DDI_0_OSC_CTL0_BYPASS_XOSC_LF_CLK_QUAL. This is one of those items I mentioned in my original post (page 429 in swcu117f says that it is "internal"). I would prefer to avoid mindlessly copying snippets of code from RTOS, if only possible. Being OS-agnostic, cc13xxware appears to be directly usable by me (in fact I have already gone through an exercise consisting in procuring a bare gcc + cc13xxware program and it works fine), but I worry that the undocumented bits used by RTOS and left out by cc13xxware will catch up with me at some point.

I guess this also answers Svend's question (thanks Svend). I am now a bit less pessimistic and I will play with it for some more time (until I hit a hard wall). I wish there were examples for bare cc13xxware, not just for RTOS. In addition to playing with the CC1350 launchpad, I have also ordered a few MSP432 boards (for an alternative solution). I will stay with TI, I guess. We have been using MSP430+CC110x/CC430 extensively in the past and are now contemplating upgrading our platform.

Thanks again and cheers!

Pawel

Thanks. This document is very helpful and seems to answer all my questions (and dispel my worries).

Cheers!

Pawel

Hi Svend,

Similar to Pawel, I have a non-RTOS MSP430 + CC110X transceiver system and would like to explore the CC1350. However, the RTOS requierment is an issue.

Can you confirm when the non-OS version will be available?
Thank you,
Vasil

Vasil: I understand you have a non-TIRTOS solution today but is it any reason why you can't implement your application using TI-RTOS on CC1350?

The short answer is cost. We do not currently use TI-RTOS. For us to use it, we need to incur the learning curve costs along with a proper set of testing - to understand the performance profile of the OS. We need to understand what risks the new "third-party" code will introduce to our product and finally, we need to factor in the on-going costs of maintenance and possible version upgrades/bug fixes. All items we have not budgeted for... There is also the matter of requirements. Our product requirements do not call for an OS - I'm not sure why we would layer on an OS just to be able to use a new chip...

The plan is to come with a non TI-RTOS solution around June.

That said that will not help you that much when it comes to time. The reason is that even when you don't use TI-RTOS you still have to use the drivers. If you use a non TI-RTOS system you have to use more time to look into the drivers and especially the power driver. In TI-RTOS the OS controls which power mode the chip should be in and it does this in a way that gives a close to power optimal solution. This makes it possible to implement a power optimal system without knowing too many details about the "behind the stage".

In the end of the day TI-RTOS is the solution that takes the shortest time to get up and running. You don't have to use that much of TI-RTOS, for a system like you have today having all the RF stuff in one task would probably be sufficient.

We can hopefully point you to relevant examples and trainings with some more details about what you need to implement.

Gentlemen,

First, I would like to thank TER for the hints and words of encouragement. It basically works now. It has been a bit tedious (our previous port from an exotic uC to MSP430 took me exactly 4 days, this one that many months). CC1350 isn't exactly a stellar example of friendliness for a non-TIRTOS person. The lack of TIRTOS-independent, authoritative reference code is really painful.

First a question:

While testing the power down modes on the launchpad (LAUNCHXL-CC1350) I cannot get in standby below some 50uA. Any immediate hints? I have disconnected it completely from the debugger, both the RF control pins are output + down (makes no difference when they are open [not output enabled]). The flash chip is unused (CS is open and pulled up by the resistor). I understand that the chip does drain a bit but not that much.

Now for a comment on TER's question to Vasil. Why not everybody loves TIRTOS and why there are people like Vasil and myself.

From our perspective, the OS running in the uC is a small part of a much larger product which is a platform for developing, running, debugging, and demonstrating wireless applications virtually. We simply cannot (it isn't even the issue of cost) use TIRTOS, because our OS must have a certain unorthodox structure and functionality which in fact belongs to the platform (being its extension into the physical device). In all my loyalty to TI, I have tried to consider patching TIRTOS (as in adding some layer to it to provide the functionality), and tweaking the platform, but it just isn't feasible for reasons more methodological than technical. So you guys should realize that (at least from where I am standing) your pushing TIRTOS on us isn't fair. It would be fair(er), if there were clear and authoritative samples of code for doing the important things independently of TIRTOS. For one of many examples, I have wasted three days trying to figure out why I cannot get down with the current (back to where I was) after switching off the RF domain. Well, there is this little operation called RFCSynthPowerDown buried inside TIRTOS. To make it trickier, there is no RFCSynthPowerUp (which would have made the guessing easier ;-). In other words, it still would have been four days altogether (which is about the time I spent on actual programming, as opposed to futilely staring at the thing and cursing the manual).

So there ARE legitimate arguments against having TIRTOS as the only toy available. It doesn't mean that we are merely stubborn and refuse to put up with "progress".

Thanks and cheers!

Pawel

TER, forget the question. I think I've got it. When I pulled up the UART RX pin, the current went down to about 8-10uA (fluctuating, probably because of the jerky nature of the recharge mechanism). The metering equipment in my basement is not good enough to measure it, and I believe that most of the drain can be attributed to the (unhandled) flash chip. You see, previously, with the (external) UART connected, the UART would leak current to the device. When I disconnected the UART, the current would go up to 50-60uA, slowly raising from about 5uA. Now (with the internal pull-up on the UART RX), it says 7uA, occasionally jumping to 12uA and back.

Sorry, I have become too talkative, I guess. Probably too much coffee, but I am also kind of excited, you know, by that light at the end of the tunnel ;-).

Cheers!

Pawel

I would also like to thank TER for the quick response.

I'm looking forward to the June update - however, I would be interested in any pre-released portions/parts of the SDK. In general, we are putting some design ideas through the business case process - and I think the cc1350 seems to have some real promise for a few of them. Is there a "beta" program that I can sign up for to get an early look at the new SDK?