CC1310 RF initialization without RTOS with error

We strongly advice to use TI-RTOS or a different RTOS using CC1310. Using TI-RTOS ensures correct timing, low power consumption with automatically setting the chip is SLEEP whenever possible etc.

Is it some specific reason you want to run without TI-RTOS?

Yes but I had firmware which I have already ported to CC1310 without RTOS and also my customer wants non rtos firmware in it. Also I am not familiar with yours TI-RTOS and I do not have much time to finish my project.
So I need some assistance with configuration radio. Maybe you have some examples without RTOS for CC1310 RF?
Thank You in advance.
BR
Tom

For CC1310 it will be faster to develop a application using TI-RTOS since the RTOS take care of a lot for you.

TI-RTOS will be the official OS supported by the CC13xx at RTM and will be the only configuration on which TI will provide examples, hands-on, trainings on etc.
For developers who absolutely have to use a different RTOS or absolutely need to go Bare Metal there will be an application note on how to implement support for both. This will involve a significant development effort on the developer’s part, mainly due to moving the power management responsibility completely in the hands of the developer but also for several other reasons, all described in the application note.

TI-RTOS
The CC13xx is an extremely powerful, flexible and high performance platform. Compared to what we've had before, it's something completely different. All of this power, flexibility and performance come at a price: Increased complexity.
There are two types of complexity in embedded systems, the complexity of the application and the complexity of the hardware. Using TI-RTOS is a way of managing both, but this topic only covers managing the hardware complexity, since that is what makes TI-RTOS unique for the CC13xx.

Power Manager and TI-RTOS enabled drivers
When using the peripherals of the CC13xx in combination with using the low-power modes the developer is quickly faced with the complexity of power and clock management. In different modes, different clocks and power domains are available, some peripherals have retention of settings, others need to have the settings restored after waking up etc. It is this flexibility that enabled the CC13xx to the ultra-low power platform it is.
Most parts of the complexity of power management in general are easy to grasp but very hard to manage without a dedicated facility to do so. The facility that has been created to handle this complexity, the Power Manager, is currently an integral part of TI-RTOS and its drivers.
The Power Manager together with the TI-RTOS enabled drivers uses the fact that it knows which peripherals that are being used at any given time, and it will always go to the lowest allowed power mode when not executing a task. This is implemented by the drivers settings Dependencies on different hardware resources and Constraints on different modes. For example, the UART driver sets a dependency on the UART peripheral, making sure that when the CC13xx is in Active mode, that power domain is always powered on and clocked. In addition to this, when the UART is actively being used, the system cannot enter Standby because of a constraint set in the UART driver.
The Power Manager will also take care of HF clock management and other system constraints, such as only powering on the XTAL when needed or when explicitly told to do so.
All settings of the Power Manager are configurable.

See www.ti.com/.../swra486. In the upcoming December release of TI-RTOS the file structure will be changed compared today making it easier to port to a different OS

Yes but this do not solve my problem at the moment. The app note will be fine but in the mean time could you please check my code and see what is wrong with my initialization. Registers values for clk and pwr seems to be ok but I get different status codes than I expected.

BR

Tom

We don't have the bandwidth to support non RTOS users.

We have a number of good examples in the latest TI-RTOS release which makes it possible to get up and running with sending/ receiving with ACK in very short time.

I just solved my problem. In app note SWRA486  that you send me there is written:

"The CC26xx/CC13xx boots with the 48-MHz high-speed RC oscillator that clocks the CM3. When using

the radio, switch the main system clock to the high-speed crystal oscillator. The code in Figure 15 shows

how to change to the high-speed crystal oscillator (see the functions in driverlib modules osc.h/osc.c)."

 

So I add before initialization:

OSCHF_TurnOnXosc();

do{}while(!OSCHF_AttemptToSwitchToXosc());

And it works now. I can send my packets to another receiver. I get proper status answers after commands.

Thanks.

 

 

Hello Tomaz,

would you be so kind to share a basic code showing the setup, low power switch and string communication only?

I think this would be helpful to many users.

Thanks,

Diego

Note that in the latest SDK (v1.4) we have examples for a nonrtos solution.

Hi,

can anybody  share a basic stratup code for CC1310 without ti-rtos?

we need to develop a secured serial bootloader for CC1310. if using ti-rtos, the bootloader code will take too much memory space.

as we need to distribute the code on the field to customer, the firmware has to be encoded.

anyway, we have the pieces of codes for the bootloader functions for other cotex M0/M3 MCU, like STM32, NXP, etc.

we just need to port it to CC1310.

but now, we are tired to get the CC1310 starting up without the Ti-RTOS.

basically a serial bootloader will only use Uart peripheries.

we once tested the uartecho sample project, when with ti-rtos, it will take about 18kbytes memory;  and when without ti-rtos (in ver 1.40 & 1.50), it will take even larger code sized @about  20kbytes.

think this size is too big for a serial bootloader.

we think the serial bootloader should be less <4kbytes (like other MCU), or, at the most, must <8Kbytes.

So we are looking for a simple startup code for CC1310, which can let us run into the main() first line code, then we'll do the next.

anybody can help us on this matter?

Thanks a lot in advance.

B/R,

Shaowei

Shaowei: Your question has been moved to e2e.ti.com/.../634361