CC1352P: Catching Specific Events in Callback

Hey M-W:

Thanks for your response and answering my main question on how to detect specific commands being completed in a sequence.  However on the 2nd part of my question wrt why transmit events are not being detected, I should have been more clear.  I had tried RF_EventTxDone originally and it didn't work.  So I tried RF_EventTxEntryDone and it didn't work either.  To be more exhaustive and using the Rx/Tx Echo example in the SDK, I created this command for the receive:

RF_EventMask terminationReason = RF_runCmd( rfHandle, (RF_Op*)&RF_cmdPropRx, RF_PriorityNormal, echoCallback, ( 0xFFFFFFFF ) );

to enable all events and I record all the events that come into the callback in an array and I get 3 different events trigger with the following entries in sequence:

0x00810000
0x00000001
0x00000003

and I do the same for the transmit command:

RF_EventMask terminationReason = RF_runCmd( rfHandle, (RF_Op*)&RF_cmdPropTx, RF_PriorityNormal, echoCallback, 0xFFFFFFFF );

and I record all the events that come into the callback in an array and I get also 3 different events trigger with the following entries in sequence:

0x00000001
0x00810000
0x00000003

all of these indicating done or last done command or a receive Ok or receive entry done.  Never can get a transmit event to be detected in the callback routine.  Am I missing something here as to why a transmit event does not get recognized even though I've indicated in the runCmd that I want it to report all events?  I know for sure a transmit packet is going out since the Rx/Tx Echo example is working, just no reporting of the transmit event in the callback on the receive or transmit board.  Please advise as to what is going on here wrt why transmit events are not being picked up in the callback routine.

Thanks,
Tim

:

Hi Tim,

I will poke around a bit internally and see if I can find any more information on this. It seems the "Tx done" flag is for IEEE and BLE only. It sounds strange that you would get RX done events for TX as well..

Tim,

Are you sure you get 0x00810000 from the TX command? Running this test using rfPacketTx example gives me only 0x3 (which is expected).

Hey M-W:

I was referring to the Rx/Tx Echo example where both of them have a receive and transmit in the chain.  So I tried the RF Packet example and found the following: 

For the transmit example, I have this command:

RF_EventMask terminationReason = RF_runCmd(rfHandle, (RF_Op*)&RF_cmdPropTx, RF_PriorityNormal, Callback, 0xFFFFFFFF );

which only creates 1 event in the callback:

0x00000003.

For the receive example, I have this command:

RF_EventMask terminationReason = RF_runCmd(rfHandle, (RF_Op*)&RF_cmdPropRx, RF_PriorityNormal, callback, 0xFFFFFFFF );

which creates 2 events in the callback:

0x00810000
0x00000003

So in conclusion, for proprietary mode the Tx event RF_EventTxDone never gets triggered and for Rx, it is only RF_EventRxEntryDone & RF_EventRxOk which assumes using a queue for receive operation.  And this is "kind of" documented in Table 25.181 of the TRM where it indicates that TX_ENTRY_DONE is supported, but only for transmission of packets of unlimited length (which I am not doing).  

So bottom line for transmit operation, there are no transmit specific events I can trigger on like RF_EventTxDone, but instead will only generate RF_EventCmdDone event and an RF_EventLastCmdDone event - if the transmit packet is the last command in the chain.  And to determine if a transmit operation has finished in the chain, I would need to look at the status entry in the transmit command within the callback routine to determine if it has changed from zero to a successful operation.  Is all of this correct?

If so, that was not intuitively obvious to the casual observer from reading the documentation.

Thanks,
Tim

Hey M-W:

Thanks for confirming and all your help/advice on this.

Thanks,
Tim