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.

CC2652R7: CMD_NOP command takes too long to execute

Part Number: CC2652R7

Tool/software:

Hi all!

Within the framework of a proprietary project, I use the NOP command.

The Technical Reference Manual (JANUARY 2018 – REVISED JUNE 2024) says that "The command can be used to test the communication between the system CPU and the radio CPU or to insert a wait."

I put this NOP command at the beginning of the chain of RF_cmdPropXXAdv commands:

RF_cmdNop.startTrigger.triggerType = TRIG_ABSTIME;
RF_cmdNop.startTrigger.pastTrig = 1;
RF_cmdNop.startTime = USEC_2_RAT_TICKS(1000000);
RF_cmdNop.condition.rule = COND_ALWAYS;
RF_cmdNop.pNextOp = (rfc_radioOp_t *) &RF_cmdPropXXAdv;

RF_cmdPropXXAdv.startTrigger.triggerType = TRIG_REL_FIRSTSTART;
RF_cmdPropXXAdv.startTime = 600; // means 150 us since NOP cmd starts
RF_cmdPropXXAdv.startTrigger.pastTrig = 1;
RF_cmdPropXXAdv.condition.rule = COND_ALWAYS;
RF_cmdPropXXAdv.pNextOp = (rfc_radioOp_t *) &RF_cmdPropYYAdv;

etc...

...

And every time the chain is completely executed, I adjust the "start" parameter of this command:

RF_cmdNopFG.startTime += 8000;  // i.e. 2000 us


and restart chain by posting  RF_cmdNop:

RF_postCmd(rfHandle, (RF_Op *) &RF_cmdNopFG, RF_PriorityNormal, RXEchoCallback, PROP_DONE_OK | PROP_DONE_RXTIMEOUT);

I noticed that the NOP command requires from 325 to 4000 ticks to execute.

Hence two questions:
- is the execution time of NOP command must be constant or near some specific value?
- if the execution time of NOP command increases, what could be the reason for that strange behavior?

Please assist

  • Hello,

    I recommend to use start time relative to current RF time.

    Something like: RF_cmdNopFG.startTime = RF_getCurrentTime() + 8000;  // i.e. 2000 us

    Also, I notice in your first code snippet you have "RF_cmdNop", vs in last code snippet you have "RF_cmdNopFG". Is this intentional?

     

    Thanks,
    Toby

  • Thank you, dear Toby, for your answer.

    Indeed I made a typo by writing RF_cmdNopFG.

    In my implementation of a proprietary protocol, using the RF_getCurrentTime() function is not desirable, since I have a synchronous protocol.

    If I use timemarks based on current RAT time, I see unacceptable packet jitter.

    Until recently, I did not use the NOP command. And everything worked fine - I achieved fairly accurate synchronization between the Host and remote Mode.

    One day there was a need to send a signal using GPIO pin at the beginning of the TX command. So I thought that the DONE_OK event of the NOP command, preceding the TX command, would be a good way to provide a hardware interrupt to the external equipment with the least resource consumption.

    But after I included NOP into the head of the command chain, everything started to behave strangely: the execution of the NOP command gradually increases. I see this by computing timedelta between the RF_getCurrentTime() value and NOP.startTime in the callback when the NOP command got DONE_OK status.

    I saw a thread here suggesting using a similar to NOP command but with different commandNo code. I tried that way, but for some reason some of the commands in the chain aren't being called.

    I haven't made any progress on this in the last few days.

    Looks like I'll have to figure out some other way to know when the TX command has started to generate IRQ signal for the external equipment.

    By the way, I still haven't figured out how to make the RF Core wink at me :) so that I would know that the next command in the chain has started.

  • Hi, Toby!

    I Routing RF Core Signals GPIO to capture the TX Stated signal from the Core.

    It turned out that I had enough.

    But NOP Command timing issue still open. Still digging on it