• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 54 subscribers
  • Views 562 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Original question:

CC1312R: CMD_FS_OFF, CMD_FS_POWERUP and CMD_FS_POWERDOWN

LPSTK-CC1352R: Proprietary RF CMD_FS / CMD_PROP_TX scheduling with DMM API

Devan Lai
Prodigy 40 points
Part Number: LPSTK-CC1352R
Other Parts Discussed in Thread: CC1312R

I'm working on a proprietary RF frequency-hopping design multiplexed with BLE using the DMM API. While I think I have a decent grasp of how the DMM policies work and how the RF API works with immediate triggers, I am a bit uncertain about some of the timing / scheduling, particularly with regards to setting the frequency.

I've seen some previous discussion on the CC1312R regarding the frequency synthesizer command caching in the single-frequency case:
https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz/f/156/t/909774

Here's my current interpretation of the proprietary RF API:

  1. The last CMD_FS command run on the handle will be implicitly applied before any CMD_PROP_TX / CMD_PROP_RX commands.
  2. If I provide an absolute start time, the RF API will take into account any settling time needed when turning on the frequency synthesizer such that the RX/TX command starts at the scheduled time
  3. In a single stack / no-DMM situation, I can chain the CMD_FS and CMD_PROP_TX together and run them in one command sequence and everything should work correctly.

In the multi-stack DMM situation, I'm not sure how I should be scheduling the CMD_FS and CMD_PROP_TX if I want to schedule the transmission with an absolute start time trigger so that it plays nice with the BLE stack.

Should I continue using one chained command? If I do, what is the correct way to fill in the timing information for RF_ScheduleCmdParams? Should I act as if the CMD_FS isn't there for the purposes of defining the activity and start time / duration / end time - or do I need to calculate the settling time myself and include that? Should I actually split up the CMD_FS and CMD_PROP_TX into two separate scheduled commands?

  • 0
    TI__Guru 58425 points

    Hi Devan,

    Those are good questions, your seems to have a good grasp of the basics and for most of the time, you could apply the same logic for DMM as well. How you would go about it in the DMM case would depend a bit on how your policy is setup but I would say that generally, chaining the FS and TX is a good tactic. While you in theory could go with not chaining them, it take much more consideration to work properly. You would first have to account for two commands potentially being pre-empted (if BLE would be of high priority at some point) and then handle the case where a FS failed and TX still was successful.

    If you went with the chained command then the situation is much easier as from a DMM point of view, it is only one command (so they are either successful or aborted as a group). As for the timing information, you could choose to fill this in how ever you want. start/duration/end time helps the DMM solve the scheduling puzzle but it is not mandatory. Taking the time to fill it in (and if you do, consider the complete chain), it could help your overall performance in the end. Which activity to assign is up to you in the proprietary case. As it is up to you to define both the activities and the Global Priority Table for this, you can choose freely how to assign these.

    As for CMD_FS execution time, you could either measure this up by routing out radio core signals and watch them with a logic analyzer, or you add a 200-250us headroom for the FS to run (this is a bit in the high region).

  • 0 in reply to IUsedToBeARealPerson (M-W)
    Prodigy 40 points

    Hi M-W,

    Thanks for clearing up that the DMM can function (albeit suboptimally) even without the detailed duration information. I think I've got a plan of action now, but I'd like to run it by you to make sure it makes sense.

    Right now I'm using the chained CMD_FS + CMD_PROP_TX where CMD_FS uses TRIG_NOW and CMD_PROP_TX uses TRIG_ABSTIME.

    Based on what you've said, this seems like it might block the other stack from scheduling anything in the intervening time from when I schedule it and the CMD_FS immediately runs and when the actual CMD_PROP_TX starts. I think I will instead change it to schedule CMD_FS with TRIG_ABSTIME + CMD_PROP_TX with TRIG_REL_FIRSTSTART so that they occupy a smaller scheduling footprint when treated as a single command.

  • 0 in reply to Devan Lai
    TI__Guru 58425 points

    Hi Devan,

    That sounds like a good plan, I would likely do something similar myself :)