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.
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...
Regarding your replies:
"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:
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).
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 .numRssiIdle = 0, // Number of consecutive RSSI measurements below the threshold needed before the channel is declared Idle .numRssiBusy = 0, // Number of consecutive RSSI measurements above the threshold needed before the channel is declared Busy .csEndTrigger.triggerType = TRIG_REL_START, // Trigs at a time relative to the command started .csEndTime = 0, }; bool txNow(){ TimeUs t = time_us(); // https://software-dl.ti.com/simplelink/esd/simplelink_cc13xx_cc26xx_sdk/5.40.00.40/exports/docs/proprietary-rf/proprietary-rf-users-guide/rf-core/rf-commands-reference/cmd_prop_cs.html txChainCs.csEndTime = 880; // first RSSI sample takes 214us + 5us, RAT tick with 250ns period, lower time produces PROP_DONE_BUSYTIMEOUT or // PROP_DONE_IDLETIMEOUT irrelevant to signal strength txChainCs.status = IDLE; // measured - takes 435us RF_runCmd(rfHandle, (RF_Op *)&txChainSetFs, RF_PriorityHigh, NULL, 0); // time must be manually counted down because of when the EMBENET_RADIO_TxNow funcion is called from GPTimer ISR then RF_runCmd returns immediately // and command is not processed properly while((uint32_t)(time_us() - t) < 435) ; if(PROP_DONE_IDLE != txChainCs.status) return false; // CHANNEL BUSY // measured posting takes 82us // measured after end of posting, signal appears with 64us delay txTransaction = RF_postCmd(rfHandle, (RF_Op *)&txChainDoTx, RF_PriorityHigh, txProcessCb, RF_EventCmdDone); // RF_EventTxDone or RF_EventMdmSoft does not work properly, so the SOF handler is called immediately if(onStartOfFrameHandler) { onStartOfFrameHandler(handlersContext, t + txSofToSignal); } return true; // OK }
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