CC1352R: CW test for Sub-1GHz

Maybe try to use SmartRF Studio.

I know, but we want to run the Sub-1GHz tests during inline testing from the firmware. Is it possible?

Actually, we use the SmartRF on the reference side in TX/RX mode for 2.4GHz and run the TX/RX test in our firmware on our device. But we don't know how to do it for Sub-1GHz.

I implemented the code from the rfCarrierWate in our project, but it hangs up after the

rfHandle = RF_open(&rfObject, &RF_prop, (RF_RadioSetup*)&RF_cmdPropRadioDivSetup_, &rfParams);

in the command

RF_runCmd(rfHandle, (RF_Op*)&RF_cmdFs, RF_PriorityNormal, NULL, 0);

because the rfHandle is NULL.


So it looks like the radio interface is busy with TI15.4 stack and can't be reused.

I guess I should run RF_close(RF_handle h) or something, but I need to know the TI15.4 handle.

How can it be solved?

I am not familiar with the TI 15.4 stack, so I will need to find someone else that can comment on that. However, I do not understand why you need to use the TI 15.4 stack for this at all. I assume that sending a CW is for some kind of RF testing and not something that you are going to do in your application. For RF testing, why do you not just make test code that run without using the stack. You can use the same PHYs as the stack does when running prop.

Siri

Hi Alex,

AlexTim said:

So it looks like the radio interface is busy with TI15.4 stack and can't be reused.

I guess I should run RF_close(RF_handle h) or something, but I need to know the TI15.4 handle.

Unfortunately there isn't an equivalent to the RF_Handle in the TI 15.4-Stack. The Stack does take ownership of the radio as you correctly pointed out, and by doing so you are limited to use the radio in a specific way (that's not really compatible with a CW test).

As Siri mentioned, for RF testing the best approach is to just make code that runs without the stack.

BR,
Andres 

The radio CW test should be a part of our main firmware. So, our device supports two stacks: BLE and TI15.4 and does the regular work in our system.

We have a CLI and a few commands to start the tests. The tests should be available in the device anytime, not only for temporary testing in production.

We can stop BLE advertising and use HCI commands to start the tests for 2.4GHz.

So, my questions are:

1. Does TI15.4 stack have an option to run the carrier test like BLE stack? Looks like your answer is "no"

2. Can we stop the TI15.4 stack and release the RF core to use the prop_rf carrier code?

Have a look at my previous answer please.

So, probably the only possible solution in my case is implementing a CLI command that would reboot the device with a flag "don't start ti15.4 stack", so the rf core for sub-1ghz would be not busy and then we could start the prop_rf carrier test. When we done the tests, we set flag "start ti15.4 stack" and reboot it again. Right?

Hi,

I managed to run the code in our project,

but it gets stuck after the command "RF_cmdTxTest".

I see in the rfCarrierWave example that it is expected behavior, because

How could I change the command

to path through and be able to return from the function to our code?

ok, thanks, I understand. Looks like I should use RF_postCmd() instead of RF_runCmd()

I noticed that the rfCarrierWave code works only when I disable BLE stack, so it doesn't depend on the TI15.4 stack at all.

If I just disable BLE advertising, it doesn't help, only disabling the whole stack with the define xBLE_START works. So it looks like when I try RF_open() in the rfCarrierWave function, it work only if one stack is active at the moment.

Also I found some similar topics:

https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/950304/cc2652p-can-rf_runcmd-don-t-block-system-cpu

https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/849979/cc1352r-combined-code-from-the-sensor-2-4g-example-and-the-rfcarrierwave-example-resetting-mcu

It's very sad that we can't run the CW test in ti15.4 projects directly without issues.

Actually I found a way to disable initialization TI15.4 stack as well. So, the rfCarrierWave works only when one of stacks (BLE or TI1.4) is disabled (or both of them). Otherwise it fails during running RF_open().