CC1352P7: RF_postCmd and RF_runCmd transmits different packets using rfc_CMD_PROP_TX_t command

Hi Devansh,

The RF_runCmd() waits for the posted command to finish before returning. 

Can you add RF_pendCmd() after the RF_postCmd() to check if the issue goes away. This is effectively equivalent to running the command. 

Since you also have added the callback function for the postCmd call. It is interesting to see if adding the pend command fixes the issue even with the presence of the callback.

Regards,

Sid

Hi Sid,

Thanks for your response, I checked with RF_postCmd and RF_pendCmd, this works perfectly but I want asynchronous call to run the command during this duration I'll acquire new packet to send in subsequent call. You can look at similar example given in rfAudioTx in simplelink audio SDK. I think I got the issue, if you see that example

    while(1)
    {
        events = Event_pend(eventHandle, Event_Id_NONE, ALL_EVENTS, BIOS_WAIT_FOREVER);

        if(events)
        {

            if(events & AUDIO_DATA_READY_EVENT)
            {
                /* Get a frame from the input buffers */
                AudioHAL_readBufGet(tlv320Handle, (void *)audioIn);
                int32_t encLen = 0;

                Packetizer_encodeFrame(packetizerHdl, audioIn, txBitStream, &encLen);

                /* Enqueue for transmission over air */
                enqueueTxFrame(txBitStream, encLen);
            }

            if (events & AUDIO_READY_TO_SEND_EVENT)
            {

                /* Are we already in TX? If that is the case just skip ahead */
                if (radioActive == FALSE)
                {
                    /* RF packet to send out */
                    uint8_t packet[TX_FRAME_SIZE];

                    /* Try to get a frame from the queue */
                    getTxFrame(&packet[1],&packet[0]);


                    /* If size is larger then 0, we got a frame */
                    if (packet[0] > 0) {

                        /* TX
                        * We have to send the Frame in two parts as the RF driver does not support data length
                        * higher than 255 bytes (each frame is 320 bytes long)
                        */
                        /* Configure the radio packet */
                        RF_cmdPropTx.pktLen = TX_FRAME_SIZE;
                        RF_cmdPropTx.pPkt = packet;
                        RF_cmdPropTx.startTrigger.triggerType = TRIG_NOW;

                        RF_CmdHandle cmdHandle = RF_scheduleCmd(rfHandle, (RF_Op*)&RF_cmdPropTx, &schParams, txDoneCB, NULL);

                        if (cmdHandle == RF_ALLOC_ERROR) {
                           while (1);
                        }

                        radioActive = TRUE;
                   }
                }
            }

            if(events & RF_TX_DONE_EVENT){

                /* One frame has been sent out */
                numberOfSentPackets++;
                if (!(numberOfSentPackets % TX_LED_TOGGLE_FREQUENCY)){
                    GPIO_toggle(Board_GPIO_LED1);
                }
            }
        }
    }

In this Event loop, 

packet is modified in getTxFrame(&packet[1],&packet[0]); there can be a case where RF driver isn't yet ready to send the immediate packet that we acquired so we're getting some random data, Although it's interesting that whatever false data I received, that didn't change across multiple test, it was always the same however wrong it was.

Currently, I found the workaround to use circular buffer like this:

if (circ_packet){
    getTxFrame(&packet0[1], &packet0[0]);
    packet = &packet0[0];
} else {
    getTxFrame(&packet1[1], &packet1[0]);
    packet = &packet1[0];
}

Can you please look into rfAudioTx example and let me know if I am missing something?

Hi Devansh,

If I understand the situation correctly, the AUDIO_READY_TO_SEND_EVENT is being triggered after one byte of data is ready. Please can you check if you can delay that event, wherever that is posted. 

Also, are you trying to migrate the audio tx example to the latest SDK?

Regards,

Sid