• State Resolved
  • Locked Locked
  • Replies 13 replies
  • Subscribers 16 subscribers
  • Views 1489 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.

CC1352R: ACK not received

Antoine VENET
Prodigy 250 points
Part Number: CC1352R

Hello,

I have an issue with the ACK frame.

Indeed I do not received the ACK frame with the IEEE 802.15.4 Receive Ack Command. I tried to do a chained command "IEEE Tx" (s_RF_cmdIeeeTx) + "IEEE receive ACK command" (s_RF_cmdIeeeTxAck), the message is correctly sent but the ACK frame is never received.

After the execution of the "RF_runCmd", the field "status" of the "s_RF_cmdIeeeTx" command is equal to 0x0806  and the field "status" of the "s_RF_cmdIeeeTxAck" command is equal to 0x00. What does these status value mean ? There is no "define" for these values....

FYI I also tried a chained command "IEEE Tx" (s_RF_cmdIeeeTx) + "IEEE receive command" and I received ACK frames but It seems that some ACK are not received and I would prefer to use "IEEE receive ACK command".

What do you suggest ? Is there a mistake in my configuration ?

Thank you for your help

Code snippet :

/* CMD_IEEE_RX_ACK
   IEEE 802.15.4 Receive Ack Command */
rfc_CMD_IEEE_RX_ACK_t s_RF_cmdIeeeTxAck =
{
    .commandNo                  = CMD_IEEE_RX_ACK,
    .status                     = IDLE,
    .startTrigger               =
    {

        .bEnaCmd                = 0x0,
        .triggerNo              = 0x0,
        .triggerType            = TRIG_NOW,
        .pastTrig               = 0,
    },
    .endTrigger                 =
    {
        .triggerType            = TRIG_REL_START,
        .pastTrig               = 0,
        .bEnaCmd                = 0x0,
        .triggerNo              = 0x0,
    },
    .condition                  = {
        .rule                   = COND_NEVER,
        .nSkip                  = 0,
    },
    .pNextOp                    = NULL,
    .seqNo                      = P_s_buffer_to_send->options_dsn,
    /* number of RAT ticks to wait before claiming we haven't received an
     * ack
     */
    .endTime                    =  RF_convertUsToRatTicks(1500),
};

/* CMD_IEEE_TX
 IEEE 802.15.4 Transmit Command */
rfc_CMD_IEEE_TX_t s_RF_cmdIeeeTx =
{
    .commandNo = 0x2C01,
    .status = 0x0000,
    .pNextOp =(RF_Op*)&s_RF_cmdIeeeTxAck,
    .startTime = 0x00000000,
    .startTrigger.triggerType = TRIG_NOW,
    .startTrigger.bEnaCmd = 0x0,
    .startTrigger.triggerNo = 0x0,
    .startTrigger.pastTrig = 0x0,
    .condition.rule = COND_STOP_ON_FALSE,
    .condition.nSkip = 0x0,
    .txOpt.bIncludePhyHdr = 0x0,
    .txOpt.bIncludeCrc = 0x0,
    .txOpt.payloadLenMsb = 0x0,
    .payloadLen = BUFFER_SIZE,
    .pPayload = u8_bufferToSend_A,
    .timeStamp = 0x00000000,
};

 /* if transmit command failed do not wait ACK */
        s_RF_cmdIeeeTx.condition.rule = COND_STOP_ON_FALSE;

        s_RF_cmdIeeeTxAck.seqNo = P_s_buffer_to_send->options_dsn;
        s_RF_cmdIeeeTxAck.endTime = RF_convertUsToRatTicks(1500);
        s_RF_cmdIeeeTxAck.endTrigger.triggerType = TRIG_REL_START;
        s_RF_cmdIeeeTxAck.startTime = TRIG_NOW;
        s_RF_cmdIeeeTxAck.condition.nSkip = 0;
        s_RF_cmdIeeeTx.pNextOp = (RF_Op*)&s_RF_cmdIeeeTxAck;

        /* just after tx command, Rx command shall be send in order to receive ACK frame */
       // s_RF_cmdIeeeRx.endTrigger.triggerType = TRIG_REL_START;
        //s_RF_cmdIeeeRx.endTime = RF_convertUsToRatTicks(MAC_RX_TIME_TICKS*32); /* Timeout to receive ACK frame */
        //s_RF_cmdIeeeTx.pNextOp = (RF_Op*)&s_RF_cmdIeeeRx;

        /* Run Tx + Rx ACK chained command */
        L_s_RFCmdResult = RF_runCmd(s_24GhzRfHandle, (RF_Op*)&s_RF_cmdIeeeTx, RF_PriorityHigh, &RxCallback2_4Ghz, RF_EventRxOk | RF_EventMdmSoft);

Environment

LAUNCHXL-CC1352R1

sdk 2.10.00.48

2.4Ghz IEEE 802.15.4

  • 0
    TI__Mastermind 23730 points
    Hi Antoine,

    Can you show me the RF_cmdRadioSetup settings?
  • 0 in reply to Severin Suveren
    Prodigy 250 points
    Hello Edvard,

    The RF_cmdRadioSetup settings :

    // Overrides for CMD_RADIO_SETUP
    uint32_t pOverrides[] =
    {
    // override_ieee_802_15_4.xml
    // PHY: Use MCE RAM patch, RFE ROM bank 1
    MCE_RFE_OVERRIDE(1,0,0,0,1,0),
    // Synth: Use 48 MHz crystal, enable extra PLL filtering
    (uint32_t)0x02400403,
    // Synth: Configure extra PLL filtering
    (uint32_t)0x001C8473,
    // Synth: Configure synth hardware
    (uint32_t)0x00088433,
    // Synth: Set minimum RTRIM to 3
    (uint32_t)0x00038793,
    // Synth: Configure faster calibration
    HW32_ARRAY_OVERRIDE(0x4004,1),
    // Synth: Configure faster calibration
    (uint32_t)0x1C0C0618,
    // Synth: Configure faster calibration
    (uint32_t)0xC00401A1,
    // Synth: Configure faster calibration
    (uint32_t)0x00010101,
    // Synth: Configure faster calibration
    (uint32_t)0xC0040141,
    // Synth: Configure faster calibration
    (uint32_t)0x00214AD3,
    // Synth: Decrease synth programming time-out (0x0298 RAT ticks = 166 us)
    (uint32_t)0x02980243,
    // DC/DC regulator: In Tx, use DCDCCTL5[3:0]=0xC (DITHER_EN=1 and IPEAK=4). In Rx, use DCDCCTL5[3:0]=0xC (DITHER_EN=1 and IPEAK=4).
    (uint32_t)0xFCFC08C3,
    // Rx: Set LNA bias current offset to +15 to saturate trim to max (default: 0)
    (uint32_t)0x000F8883,
    // override_frontend_id.xml
    (uint32_t)0xFFFFFFFF,

    };




    /* CMD_RADIO_SETUP
    Radio Setup Command for Pre-Defined Schemes */
    rfc_CMD_RADIO_SETUP_t RF_cmdRadioSetup =
    {
    .commandNo = 0x0802,
    .status = 0x0000,
    .pNextOp = 0, // INSERT APPLICABLE POINTER: (uint8_t*)&xxx
    .startTime = 0x00000000,
    .startTrigger.triggerType = 0x0,
    .startTrigger.bEnaCmd = 0x0,
    .startTrigger.triggerNo = 0x0,
    .startTrigger.pastTrig = 0x0,
    .condition.rule = 0x1,
    .condition.nSkip = 0x0,
    .mode = 0x01,
    .loDivider = 0x00,
    .config.frontEndMode = 0x0,
    .config.biasMode = 0x0,
    .config.analogCfgMode = 0x0,
    .config.bNoFsPowerUp = 0x0,
    .txPower = 0x001F,
    .pRegOverride = pOverrides,
    };
  • 0 in reply to Antoine VENET
    TI__Mastermind 23730 points
    The CMD_IEEE_RX has the option to auto-ack packages with the frameFiltOpt.autoAckEn = 1 setting. This way you don't have to manually send acknowledgment with the CMD_IEEE_RX_ACK command. Can you show me the CMD_IEEE_RX settings as well?
  • 0 in reply to Severin Suveren
    Prodigy 250 points
    Auto-ack option is working (when I received a data frame, ACK frame is correclty transmitted).

    My issue is that "ACK" frame is not received after a data frame transmission.
  • 0 in reply to Antoine VENET
    TI__Mastermind 23730 points
    Are you expecting to receive the ACK frame as a packet in your application? If so, this is not the case with IEEE RF commandos when the auto-ack option is set, as they are handled entirely by the radio.
  • 0 in reply to Severin Suveren
    Prodigy 250 points
    For me auto-ack option is used only when a data frame is received by CC1352R and it's working for my setup.

    As I said in my previous post, I'd like to know if a data frame sent has been acknowledged.
    TI provides a dedicated command "CMD_IEEE_RX_ACK " (in driverlib) which checks if the correct ACK (with the same DSN as frame sent) has been received but this command does not work as I explain previously.

    I'd like to know if this command works ? Or if there is a other mean to check if a sent frame has correctly been acknowledged.

    Regards,
  • 0 in reply to Antoine VENET
    TI__Mastermind 23730 points
    I see.

    I can now see that your CMD_IEEE_TX returned with status 0x0806. This means ERROR_WRONG_BG, which means you had a BG command running at the time you posted CMD_IEEE_TX, however, they were not compatible to run at the same time. Which command are you running when posting CMD_IEEE_TX?
  • 0 in reply to Severin Suveren
    Prodigy 250 points

    No command are running when I post CMD_IEEE_TX.

    If I understand well, I need to post a CMD IEEE RX before running chainned command CMD_IEEE_TX+CMD_IEEE_RX_ACK ? Or I need to post a chainned command CMD_IEEE_TX+CMD_IEEE_RX+CMD_IEEE_RX_ACK ?

    I am not sure to understand the need to be in "Rx mode" during frame transmission (the power consumption will be increased ?)

  • 0 in reply to Antoine VENET
    TI__Mastermind 23730 points
    Are you entirely sure? CMD_IEEE_TX having a status of 0x0806=ERROR_WRONG_BG indicates something is not right.

    Are you running any other RF commands in your applications, except for CMD_IEEE_TX and CMD_IEEE_RX_ACK?
  • 0 in reply to Severin Suveren
    Prodigy 250 points

    Yes I am sure.

    Even if the status CMD_IEEE_TX is 0x0806, the frame is correclty transmitted. But the command CMD_IEEE_RX_ACK is not executed and the ACK is not received.

    The status 0x0806 seems to be linked to the next command in the chain (here CMD_IEEE_RX_ACK). Indeed in the datasheet, it seems that IEEE_RX_ACK needs a background command to be executed (page 1889 of SWCU185). Is that true ? Could you give me a code sample which uses the chainned command (TX+RX ACK) with the correct background command ?

    Thank you for your help

  • 0 in reply to Antoine VENET
    TI__Mastermind 23730 points

    So I am also working just now on implementing RX ACK on IEEE on another project. It seems I haven't bumped into the same problem as you since I have RX-on-idle. When I stopped RX before transmitting I got the same problem as you.

    I found out that you can do the following to setup RX when expecting ACK:

    RF_CmdHandle cmd_rx_handle;

bool expect_ack = do_expect_ack(); /* implementation omitted */
bool rx_active = is_rx_active(); /* implementation omitted */

RF_ScheduleCmdParams sched_params;
RF_ScheduleCmdParams_init(&sched_params);

if (expect_ack && !rx_active) {
    cmd_rx_handle = RF_scheduleCmd(rf_handle, (RF_Op*)&RF_cmdIeeeRx, &sched_params, 0);
}

RF_runScheduleCmd(rf_handle, (RF_Op*)&RF_cmdIeeeTx, NULL, 0);

if (expect_ack && !rx_active) {
    RF_cancelCmd(rf_handle, cmd_rx_handle, RF_ABORT_GRACEFULLY);
}

/* You can now inspect status of RF_cmdIeeeRxAck */

    Be aware of the lack of error handling, and that I've omitted some implementation details. 

    Also, your triggers looks good for CMD_IEEE_RX_ACK. I just want to comment that after experimentation I've found out that 700 us for endTime is sufficient.

  • 0 in reply to Severin Suveren
    Prodigy 250 points
    Ok it's working better when executing an RX command before Tx command. I'm thinking that CMD_IEEE_RX_ACK set the RF core in RX mode.

    By curiosity why do you use RF_scheduleCmd instead of RF_postCmd ?

    Do you know if there are code samples for IEEE radio commands ?
  • 0 in reply to Antoine VENET
    TI__Mastermind 23730 points
    This has to do with Foreground and Background command scheduling by the RF driver. I can't say for sure, but I believe proper FG & BG scheduling by the RF driver requires you to use the RF_scheduleCmd() API.

    Sadly, there aren't any good IEEE radio command usage examples.