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.

LAUNCHXL-CC1312R1: LAUNCHXL-CC1312R1: the proper use scheme of RF API

Part Number: LAUNCHXL-CC1312R1
Other Parts Discussed in Thread: CC1312R

Tool/software:

Hello,

In our company I am porting our 6TiSCH stack to CC1312R (863-870MHz band). The TSCH scheme introduces strict timing requirements therefore the transceiver is managed by a timer.

The device configuration overview (simplelink_cc13xx_cc26xx_sdk_7_41_00_17, nortos):
- GPTIMER to run tasks in the system (MAC layer operations are launched in GPTIMER ISR context)
- UART to border router communication
- RF with custom configuration
- AESECB, TRNG, etc.

My problem 1:
Priorities setting:
Timer1.timerInstance.interruptPriority = "6";
RF.interruptPriority         = "1";
RF.softwareInterruptPriority = "1";
The thing is that RF_runCmd hangs the MCU infinitively when the funcion is called from the GPTIMER ISR context.

My problem 2:
RF.softwareInterruptPriority = "1"; - application starts
RF.softwareInterruptPriority = "2"; - application starts
RF.softwareInterruptPriority = "3"; - application starts
RF.softwareInterruptPriority = "4"; - hard fault exception (call stack indicates the SemaphoreP_Params_init function)
RF.softwareInterruptPriority = "5"; - hard fault exception (call stack indicates the SemaphoreP_Params_init function)
....
Why does it works that way?

Question 1.
How does the RF driver works?
Radio hardware raises interrups, they are processed internally by the driver in ISR context, then a software interrupt is raised from which the radio callbacks are called?

Question 2.
What in syscfg is a software interrupt priority? Is this the priority TI drivers components execution when software interrupt is raised (aka. SWI)?

Question 3.
What priority has the SWI and why this interrupt priority is not configurable in SYSCFG? Eg. if in the GPTIMER ISR I want a complete execution of radio command, the RF ISR and the RF software ISR are involved. Therefore, the RF ISR must preemtp the GPTIMER ISR and RF software ISR must preempt the RF ISR. I do not know what RF software ISR can preempt and whan it can not preempt.

  • Hi Mateusz,

    RF_runCMD is blocking and can not be called from an ISR.

    Can you please explain:
    1. Which of our software stacks are you using?
    2. Are you using an RTOS?

    About your questions:
    1. Our RF driver is documented here: https://dev.ti.com/tirex/explore/content/simplelink_cc13xx_cc26xx_sdk_7_41_00_17/docs/proprietary-rf/proprietary-rf-users-guide/proprietary-rf-guide/rf-core-index.html# and here https://dev.ti.com/tirex/explore/node?node=A__AIW3BFKR-3ew-wxtbzaH-A__com.ti.SIMPLELINK_CC13XX_CC26XX_SDK__BSEc4rl__LATEST

    2. There is nothing like this in .syscfg. 

    3. The hardware interrupts will always be higher prioritized as any software interrupts. Did you read through our RTOS documentation: https://dev.ti.com/tirex/explore/node?node=A__AGhAXIxP6gouUA7QxaW0Lg__com.ti.SIMPLELINK_CC13XX_CC26XX_SDK__BSEc4rl__LATEST and also general RTOS guides.

    In general I think the scheduling that you want to achieve should be done by RTOS task prisonization. But please explain me in more detail which radio operation you want to perform and which software stack you want to run on.

    Kind reagards,
    Theo

  • Hello Theo, thank you for your reply and sorry for the delay from my side...

    1. I am only using the simplelink_cc13xx_cc26xx_sdk_7_41_00_17.
    2. No rtos is used, set in the syscfg file: --rtos "nortos".

    Regarding your replies:

    1. Thank you for the links. I've looked into them before. I appreciate your contribution to detailed and reliable documentation.
    2. OK, understandable.
    3. No rtos is used in our application. I will try to read more into the documentation.

    "In general I think the scheduling that you want to achieve should be done by RTOS task prisonization. But please explain me in more detail which radio operation you want to perform and which software stack you want to run on."

    We are intentionally not using rtos in our library development for couple of reasons:

    • Portability - the library is to be able to be used without or with an operating system, we are far from integrating with any operating system because it is optional in our product (customers integrate it with what they want).
    • Strict timing margins - our stack (6TiSCH) requires the radio to operate in strict timings regime (like in BLE) and it will be problematic for any operating system to handle it all with microsecond precision. Critical, possibly short operations must be performed in privileged mode, the rest is delegated to the thread/application context (again like Controller and Host in BLE).
    • The port's API is already established - our product is already mature and it's hard for us to change the port API. We rather care about matching TI drivers to the port API than vice versa. We already have many other chips working with our software that way.

    By chance my early developing platform was application with FreeRTOS (syscfg argument: --rtos "freertos"). In GPTIMER ISR I run radio API function to start transmission. This simplified code snippet works predictably with deterministic execution time, so transmission may be executed in advance to meet the strict transmission timings (the listening before talk feature also was tested with positive result).

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    static rfc_CMD_FS_t txChainSetFs = {
    .commandNo = CMD_FS,
    .startTrigger.triggerType = TRIG_NOW,
    .pNextOp = (RF_Op *)&txChainCs,
    .condition.rule = COND_STOP_ON_FALSE,
    .synthConf.bTxMode = 0x1, // Start FS in Tx Mode, this option seems to be unused (even in example code)
    };
    static rfc_CMD_PROP_CS_t txChainCs = {
    .commandNo = CMD_PROP_CS,
    .pNextOp = 0,
    .startTime = 0,
    .startTrigger.triggerType = TRIG_NOW, // Triggers immediately
    .condition.rule = COND_NEVER, // COND_STOP_ON_FALSE, // Run next command if this command returned True, stop if it returned False
    .csFsConf.bFsOffIdle = 0, // Keep synth running if command ends with channel Idle
    .csFsConf.bFsOffBusy = 0, // Keep synth running if command ends with channel Busy
    .csConf.bEnaRssi = 1, // enable RSSI as a criterion
    .csConf.busyOp = 0, // continue carrier sense on channel Busy
    .csConf.idleOp = 0, // continue on channel Idle
    .csConf.timeoutRes = 1, // Timeout with channel state Invalid treated as Idle
    .rssiThr = -80, // RSSI threshold
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    However, this part, and couple of others, works differently without rtos (syscfg argument: --rtos "nortos").

    I managed to make it work with and without rtos, but without the listening before talk feature in transmission function. Now my objective is to implement a blocking function which gives me yes or no result whether the transmission started or not. Preferably with exactly 160 us of listening period and minimum code execution overhead.

  • Hi Mateusz,

    thank you for explaining this in more detail.

    In this case I really recommend you to look at our propRF examples and the porting guide for no rtos: https://dev.ti.com/tirex/explore/node?node=A__AKCeocMrM0I9bD1wOkaUEA__com.ti.SIMPLELINK_CC13X0_SDK__eCfARaV__LATEST&placeholder=true and https://dev.ti.com/tirex/explore/content/simplelink_cc13x0_sdk_4_20_02_07/docs/simplelink_mcu_sdk/Users_Guide.html#nortos 

    Additionally you can find doxygen documentation of the RF drivers shipped with the SDK that I recommend you to review as it will provide you with the necessary understanding on how the driver interacts with the radio core.

    We can not provide support in case that you are moving away from using our drivers.

    Let me know afterwards if I can help clarifying something even further.

    Kind regards,
    Theo