• State TI Thinks Resolved
  • Locked Locked
  • Replies 2 replies
  • Answers 1 answer
  • Subscribers 54 subscribers
  • Views 111 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

CC1354R10: RF examples - safe execution of RF commands when they are preempted

Angel Trendafilov
Intellectual 315 points
Part Number: CC1354R10


Tool/software:

Hello,

We are developing a new device using CC1354R10 with BLE and proprietary UHF protocol. The project is base on the latest SDK 8.31.00.11.

We checked very carefully all RF proprietary examples. My questions are about the function RF_runCmdSafe(...). We understand the idea that one command can be preempted 

by another command with higher priority. Applies only to multi-client applications.
Questions:
1. Why the verifications is while(( terminationReason & RF_EventCmdAborted ) && ( terminationReason & RF_EventCmdPreempted ))?
2. Why do you check for RF_EventCmdAborted event? Only the RF_EventCmdPreempted event is for preempted command.
3. Why the verification is AND, nor OR? Does it mean that both events will be generated for preempted command?
4. Why don't you check for RF_EventCmdCancelled, RF_EventCmdStopped and RF_EventError events?
5. Why don't you use the RF_runCmdSafe(...) function for the first command to start the FS (not in all example project)?
About the last question, we succeeded to catch a case where the command for the FS is executed with RF_EventLastCmdDone event, but the command status is not DONE_OK. The returned status was ERROR_SYNTH_PROG - Synthesizer Calibration failed. This is very rear case (once per 500000 commands but it happens). Is it possible to happen?
In that case, the next question  is:
Is it better the  RF_runCmdSafe(...) command also to check the returned command status DONE_OK or PROP_DONE_OK?
Thank you very much for your advices in advance.
  • 0
    TI__Guru* 82511 points

    Hi Angel,

    Are you using the DMM? Or handling everything through the multi mode of the RF driver?

    1. & 2. In the DMM context, a command can be either preempted or aborted by the DMM Scheduler depending on the scenario. So you should handle both.

    3. If it's possible to have more than one event in the queue, we recommend this syntax.

    4. You can check for these events as well. 

    5. When you send a CMD_FS, the radio will not run it immediately but wait until there is an rx og tx scheduled. So this doesn't really make sense for CMD_FS.

    6. Yes it's possible that CMD_FS fails. When this happens, the following Tx or Rx command will fail. You should make sure this error is handled. 

    Cheers,

    Marie H

  • 0 in reply to Marie H
    Intellectual 315 points

    Hi Marie H,

    1. Yes, we use the DMM in the project.

    2. The recommended syntax is "while(( terminationReason & RF_EventCmdAborted ) && ( terminationReason & RF_EventCmdPreempted ))".

    That means, the RF command will be repeated ONLY if both events exist. If it is aborted OR preempted, the RF command will not be repeated. This is not the purpose.

    If the syntax was "while(( terminationReason & RF_EventCmdAborted ) || ( terminationReason & RF_EventCmdPreempted ))", the RF command will be repeated if the first event OR the second event OR both events exist.

    One last question.

    In our RF proprietary protocol and RF commands, we use the function RF_yield(rfHandle); before to close the rfHandle. Is that a problem for the BLE stack, which works in parallel?

    Cheers,

    Angel