RTOS/CC1310: RF parameter setting problem

user4959119

Part Number: CC1310

Tool/software: TI-RTOS

Hi Team，

On the basis of WOR-RX, I need to set several RF parameters at one time in another task: working frequency, Tx power .Since the Rxsniff command keeps entering and exiting, I can't set it up right away.I think the core issue to consider when modifying these parameters is the scheduling of RF commands.

1.First of all, how to efficiently set the working frequency and avoid conflict with the Rxsniff command during the run, RF_control()? For example, I want to change 433MHz to 434MHz. I hope you can give a code snippet.

2.RF_setTxPower() also executes a command, it also needs to consider conflicts with other commands？

3.When a command is executed, the RF core is in the IDLE state. Is the call to the RF_cmdCancel() API equivalent to a null operation?

4.How to judge whether the RF core is in the IDLE state, is there any relevant API available?

over 6 years ago

0 IUsedToBeARealPerson (M-W) over 6 years ago

TI__Guru 58425 points

Hi X,

1) You change the frequency by updating the FS command you use to the new frequency. This means that to change frequency, you also need to run the "CMD FS"command again with the new frequency.

2) This API takes effect immediate if the radio is active, as stated by the documentation. If it can cause an issue in your application, I would consider making sure this does not interfere with another command but I would expect you to be OK either way.

3) You can only cancel a command that is already posted, which means it always result in you either removing a command from the queue, or stopping/aborting it if it is running.

4) I'm not sure why you want this information, could you elaborate on it? Unless there is a command in the queue to run, the RF driver would typically try to shut down the RF core to save power which means it is really only "active" or "shutdown" unless you asked the driver to keep it on at all time.

0 user4959119 over 6 years ago in reply to IUsedToBeARealPerson (M-W)

Expert 2215 points

Hi M,
I think my current question has not been completely eliminated.

1.Which parameters in the FS structure should I modify when setting the frequency?Can RF_control() be implemented?

2.You said that such an API can take effect immediately when the RF core is active. Does this active state mean that the RF core can run as long as it has power or immediately when the kernel is idle?

3.Yes, I posted a command. When the command has been executed, will the RF kernel automatically delete the commands in the queue?If deleted, will the application execute Cmdcancel once and cause unsafe results?

0 IUsedToBeARealPerson (M-W) over 6 years ago in reply to user4959119

TI__Guru 58425 points

Hi X,

What changes you need to do to the FS structure depends on multiple things. In the easiest of scenarios, you simply change the "freq" field but you might also need to adjust other parts. The best you can do in this case is to use SmartRF Studio to setup the PHY with the desired settings and look on the structure it generates for you. There is no plans to implement such APIs in the RF driver, you are however free to implement your own "Change Frequency" functions.

Active state simply refers to the statue of the RF core which is the core not being turned of. The RF Core is a peripheral which means it can run independently of the main CPU and as long as it has power. The RF driver typically sees to it that it is shutdown when not needed to save on power consumption.

As for 3), while I would not expect any big issues here, you should not be calling cancel on any commands that is currently not in use. The behavior might be unpredictable just as for any driver if you use a handle that is no longer valid.

0 user4959119 over 6 years ago in reply to IUsedToBeARealPerson (M-W)

Expert 2215 points

Hi M-W,
As for 3),do you mean that if I use Cmdcancel, there must be instructions in the RF kernel? In my application, Rxsniffcmd runs in one task, while another task may need to be modified at any time. When I want to execute the CmdFs command, Rxsniffcmd may be executed. The RF core is IDLE. As you say I can't use Cmdcancel. What method should I use to solve this problem?

0 IUsedToBeARealPerson (M-W) over 6 years ago in reply to user4959119

TI__Guru 58425 points

Hi X,

I'm not sure I fully understand your setup, but you should really avoid splitting your RF code across multiple tasks (as with any peripheral) unless you can guarantee a behavior where they do not collide. Sound to me that you should build up a radio control task and issue events to this single task from the other task (to assure you have full control and insight into what you are doing with the radio).

0 user4959119 over 6 years ago in reply to IUsedToBeARealPerson (M-W)

Expert 2215 points

Hi M-W，

It is unlikely that my application will put RF operations in one task.The following two tasks are shown, the purpose of which is to achieve RF conflicts.

/* WOR-RX task priority =2*/
while(1)
{
   /* Get access to resource */
   Semaphore_pend(semHandle, BIOS_WAIT_FOREVER);
        
   /* Set next wakeup time in the future */
   RF_cmdPropRxSniff.startTime += WOR_WAKE_UP_INTERVAL_RAT_TICKS(SetPara.wakeTime);

   /* Schedule RX */
   rxCmdhandle = RF_postCmd(rfHandle, (RF_Op*)&RF_cmdPropRxSniff, RF_PriorityNormal, &callback, RF_EventRxEntryDone);
   RF_pendCmd(rfHandle, rxCmdhandle, 0);

   /* Unlock resource */
   Semaphore_post(semHandle);
}

/*UART task priority =4*/
while(1)
{
  Set Frequency instruction;
  ....
  if(Semaphore_pend(semHandle, 0) == FALSE)
  {
    if(!EasyLink_CmdHandle_isValid(rxCmdhandle)) return FALSE;
    RF_Stat status = RF_cancelCmd(rfHandle, rxCmdhandle, 1);
    UART_write(uartHandle,&status,1);
    if(status != RF_StatSuccess) return FALSE;
  }
  ....
}

When I set the frequency for the first time, status = 0x83, but then set status = 0x04. I think my idea can avoid RF command conflicts, but the actual result is like this. What is the reason and how to solve it?

0 IUsedToBeARealPerson (M-W) over 6 years ago in reply to user4959119

TI__Guru 58425 points

Hi X,

You can not use the Easylink API to check if a command is valid, it simply checks if the handle is not negative. I don't know what to tell you here expect that you would need to assure thread safety to some degree when sharing handles across tasks.

As for return values, these are defined in the header file, just look for RF_Stat.

0 user4959119 over 6 years ago in reply to IUsedToBeARealPerson (M-W)

Expert 2215 points

Hi M-W,
Yes, I can remove the ported Easylink API.The semaphore is used in my code to protect the shared handle, but it has an error. Can you teach me the right way?

0 IUsedToBeARealPerson (M-W) over 6 years ago in reply to user4959119

TI__Guru 58425 points

Hi X,

I'm not sure what you mean by error, could you elaborate? How did you created the semaphore prior to using it in your code?

0 user4959119 over 6 years ago in reply to IUsedToBeARealPerson (M-W)

Expert 2215 points

Hi M-W,
There is no problem with my semaphore creation. I mean RF_Stat status = RF_cancelCmd(rfHandle, rxCmdhandle, 1); The status value returned by each delete is always 0x04, I checked the related post, it looks like our driver is a bit problematic. My goal is very simple, to achieve non-conflicting access to the RF kernel in two tasks, please give me a method.

0 IUsedToBeARealPerson (M-W) over 6 years ago in reply to user4959119

TI__Guru 58425 points

Hi X,

As given my the RF_Stat enum, 0x04 means RF_StatCmdEnded (Cmd is found in the pool but was already ended). The fact still stands that if you intend to share drivers (in general) across multiple threads, you should implement the appropriate features needed in order to make your usage "thread safe" when needed. Exactly how you do this varies depending on your usage of said driver.

While you could possibly "make due" with simply calling cancelCmd(), relying on the RF driver to figure it out for you, I would still recommend you also keep track of this yourself in your application. In other words, one thread should know if the other threads RF command is still valid or not (for example, if/when you receive a "CMD done" flag, set the handle to NULL and perform NULL checks in your application).

Sub-1 GHz

Sub-1 GHz forum

RTOS/CC1310: RF parameter setting problem