LAUNCHXL-CC1352R1: Issue Flashing Code with IEEE 802.15.4 Configuration with sysconfig

Hello Xiaopeng,

You are using the following commands for the IEEE version of the PHY correct?: (also which SDK is this on) 

yes，because code composer can not build with CMD_PROP_TX_ADV and CMD_PROP_RX_ADV

Hello Xiaopeng Fan,

I pulled the CC13xx/CC26xx example and it seems like what we will need to do here is fix the RF_CMDxxx to the IEEE versions:

// RF Core API commands
extern rfc_CMD_RADIO_SETUP_PA_t RF_cmdRadioSetup_ieee154_0;
extern rfc_CMD_FS_t RF_cmdFs_ieee154_0;
extern rfc_CMD_IEEE_TX_t RF_cmdIeeeTx_ieee154_0;
extern rfc_CMD_IEEE_RX_t RF_cmdIeeeRx_ieee154_0;

And since you are trying to use a IEEE PHY that is not available on syscfg we will need to bring in a local copy of the rcl_settings.c and rcl_settings.h while excluding the syscfg ti_radio_config.h. 

Thanks,
Alex F

i am using the rfSynchronizedPacketTx and Rx examples under TI Proprietary RF. If i fix the RF_CMDxxx to the IEEE versions manuelly, then i have errors when i try to compile 

src/task_SynchronizedPacketTX.c:133:17: error: 'rfc_CMD_IEEE_TX_t' {aka 'struct rfc_CMD_IEEE_TX_s'} has no member named 'pktLen'
133 | RF_cmdPropTx.pktLen = sizeof(message);
| ^
src/task_SynchronizedPacketTX.c:134:17: error: 'rfc_CMD_IEEE_TX_t' {aka 'struct rfc_CMD_IEEE_TX_s'} has no member named 'pPkt'
134 | RF_cmdPropTx.pPkt = (uint8_t*)&message;
| ^
make: *** [Makefile:201: _build/src/task_SynchronizedPacketTX.o] Error 1

Hello Xiaopeng,

Looking at the struct of the IEEE we need to change the pktLen to payloadLen, and pPkt to pPayload: 

#define CMD_IEEE_TX                                             0x2C01
//! IEEE 802.15.4 Transmit Command
struct __RFC_STRUCT rfc_CMD_IEEE_TX_s {
   uint16_t commandNo;                  //!<        The command ID number 0x2C01
   uint16_t status;                     //!< \brief An integer telling the status of the command. This value is
                                        //!<        updated by the radio CPU during operation and may be read by the
                                        //!<        system CPU at any time.
   rfc_radioOp_t *pNextOp;              //!<        Pointer to the next operation to run after this operation is done
   ratmr_t startTime;                   //!<        Absolute or relative start time (depending on the value of <code>startTrigger</code>)
   struct {
      uint8_t triggerType:4;            //!<        The type of trigger
      uint8_t bEnaCmd:1;                //!< \brief 0: No alternative trigger command<br>
                                        //!<        1: CMD_TRIGGER can be used as an alternative trigger
      uint8_t triggerNo:2;              //!<        The trigger number of the CMD_TRIGGER command that triggers this action
      uint8_t pastTrig:1;               //!< \brief 0: A trigger in the past is never triggered, or for start of commands, give an error<br>
                                        //!<        1: A trigger in the past is triggered as soon as possible
   } startTrigger;                      //!<        Identification of the trigger that starts the operation
   struct {
      uint8_t rule:4;                   //!<        Condition for running next command: Rule for how to proceed
      uint8_t nSkip:4;                  //!<        Number of skips + 1 if the rule involves skipping. 0: same, 1: next, 2: skip next, ...
   } condition;
   struct {
      uint8_t bIncludePhyHdr:1;         //!< \brief 0: Find PHY header automatically<br>
                                        //!<        1: Insert PHY header from the buffer
      uint8_t bIncludeCrc:1;            //!< \brief 0: Append automatically calculated CRC<br>
                                        //!<        1: Insert FCS (CRC) from the buffer
      uint8_t :1;
      uint8_t payloadLenMsb:5;          //!< \brief Most significant bits of payload length. Should only be non-zero to create long
                                        //!<        non-standard packets for test purposes
   } txOpt;
   uint8_t payloadLen;                  //!<        Number of bytes in the payload
   uint8_t* pPayload;                   //!<        Pointer to payload buffer of size <code>payloadLen</code>
   ratmr_t timeStamp;                   //!<        Time stamp of transmitted frame
} __RFC_STRUCT_ATTR;

thanks a lot for your answer， it inspired me to understand more about those parameters in the radio files.

I have already found a solution about this question. Refering to the question "https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1415005/lp-cc1352p7-no-transmission-when-using-rf_cmdproptxadv" and the technical reference manul, i just edited the packet by adding one length byte and a whitening byte ,and also adjusting the TX RX codes for the packet. Because the strukturs of CmdIeee and CmdAdv have so many differences, i didnt dare to modify the command by myself.

I have another question now, its understandable that default setting from "IEEE 802.15.4, 50 kbps, 25 kHz Deviation, 2-GFSK, 100 kHz RX Bandwidth." has to be CmdAdv. Because Ieee has a certain rule for packet. But why the dafault setting from "200 kbps, 50 kHz Deviation, 2-GFSK, 311 kHz RX Bandwidth" has also the CmdAdv? And why some of the normal ti-proprietary Setting use just normal command like "Sub-1 GHz Frequency Band (779–930 MHz)----50 kbps, 25 kHz Deviation, 2-GFSK, 100 kHz RX Bandwidth"? And some use Adv command? I dont see there is any significant differences between thoses Setting.

Best wishes

Hello Xiaopeng,

To give a little context depending on what underlying command headers the PHY is meant to be used with will change the commands we use in practice. For example IEEE have their own commands comparted to the generic commands, with that being said both commands will eventually use similar LRF commands at a low level. 

I am not as familiar with sub-1 as I am with 2.4 GHz, however following the experience with 2.4 GHz we tend to use what commands the PHY was designed around, and quite often they do share many similarities. Sometimes we see differences between the internal command structure (ACK for example). 

Thanks,
Alex F