• State Resolved
  • Locked Locked
  • Replies 27 replies
  • Answers 5 answers
  • Subscribers 57 subscribers
  • Views 6500 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.

CC1310 hangs on a standard example rfWsnNode

Ilya Volkov
Intellectual 260 points
Other Parts Discussed in Thread: CC1310, CC2650, CC1350, CC2530, Z-STACK, CC2630, CC2538, TIMAC

I can't to solve one problem with the system hanging when active transmitission is going on the radio channel.
On first device programmed standard example rfWsnConcentrator, without any changes.
On second device programmed standard example rfWsnNode, with only one change in file "NodeTask.c" (removed waiting for an event of new ADC data):

static void nodeTaskFunction(UArg arg0, UArg arg1)
{
/* Open LED pins */
ledPinHandle = PIN_open(&ledPinState, pinTable);
if(!ledPinHandle) {
System_abort("Error initializing board 3.3V domain pins\n");
}

/* Start the SCE ADC task with 1s sample period and reacting to change in ADC value.
* A change mask of 0xFF0 means that changes in the lower 4 bits does not trigger a wakeup.*/
SceAdc_init(0x00010000, 0xFF0);
SceAdc_registerAdcCallback(adcCallback);
SceAdc_start();

while(1) {
// /* Wait for event */
// uint32_t events = Event_pend(nodeEventHandle, 0, NODE_EVENT_ALL, BIOS_WAIT_FOREVER);
//
// /* If new ADC value, send this data */
// if(events & NODE_EVENT_NEW_ADC_VALUE) {
/* Toggle activity LED */
PIN_setOutputValue(ledPinHandle, NODE_ACTIVITY_LED,!PIN_getOutputValue(NODE_ACTIVITY_LED));

/* Send ADC value to concentrator */
NodeRadioTask_sendAdcData(latestAdcValue);
// }
}
}

So I wanted to test the stability of the software part of the radio channel.
When I run the project, the system is running 5-30 seconds and hangs.


Tools for development:
TI-RTOS: tirtos_cc13xx_cc26xx_2_15_00_17;
IAR v.7.50.2

Just in case, I attach my examples.projects.zip

Please help me to deal with this situation.
Thanks in advance for your help.

  • 0
    TI__Genius 9180 points
    Hi,
    I have tried to replicate this issue without success. Can you help me understand more about the issue that you are seeing?

    - Is it the node or the concentrator that hangs?
    - What is the symptom of the hang? Do the LEDs stop flashing? Do you see the issue with the debugger attached and if so can you halt on the board that hangs to see what code is running?

    Regards,
    TC.
  • 0 in reply to TopCat
    Intellectual 260 points

    Both devices (node and concentrator) may hang.

    The symptom of the hang is radioactivity stop.

    I can see the issue with the debugger attached and here is some information:

    - The problem occurs when a radio reception, by using the function EasyLink_receiveAsync;

    - When device hang, all counter values of semaphores and radioOperationEvent is a equal to zero;

    - nodeTaskFunction stay forever  at Semaphore_pend(radioResultSemHandle, BIOS_WAIT_FOREVER) in function NodeRadioTask_sendAdcData;

    - nodeRadioTaskFunction stay forever at uint32_t events = Event_pend(radioOperationEventHandle, 0, RADIO_EVENT_ALL, BIOS_WAIT_FOREVER);

    - busyMutex was pended by EasyLink_receiveAsync, but never comes in rxDoneCallback and due to this device is hang;

  • 0 in reply to Ilya Volkov
    TI__Genius 9180 points
    It sounds like EasyLink_receiveAsync is being called again before it completes, his would cause it to block on the busyMutex until the previous call has completed. However this should not happen in this example and even if it did then an Rx should cause it to unblock.

    Can you try removing RF_EventRxAborted from the EASYLINK_RF_EVENT_MASK in EasyLink.c:

    #define EASYLINK_RF_EVENT_MASK ( RF_EventLastCmdDone | RF_EventCmdError | \
    RF_EventCmdAborted | RF_EventCmdStopped | RF_EventCmdCancelled | \
    RF_EventRxAborted )

    We have seen this causing issues elsewhere and it will be removed in the next TIRTOS release.

    In the mean time I will test your project in IAR, I previously tested the source in CCS.

    Regards,
    TC
  • 0 in reply to TopCat
    Intellectual 260 points
    I removed RF_EventRxAborted from the EASYLINK_RF_EVENT_MASK in both projects. Project rfWsnNode began to work much more stable, but still hanging after 5-10 minutes of work. At project rfWsnConcentrator situation has not changed.

    New details of what is happening, i try to understand tomorrow.

    Today found some details that might help you. Initially, when I posted my problem, I worked with the boards of its own design, and today decided to try these examples on the evaluation board. On the evaluation board, these examples worked for an hour before the first hang.

    Then rfWsnNode project i launched in the debug board and rfWsnConcentrator on the board of its own design. And I saw that both projects hang alternately.
    Next, I got your message with a recommendation to delete RF_EventRxAborted from the ASYLINK_RF_EVENT_MASK. And I got a situation which is described at the beginning of this message.

    I assume that this issue can be more easily catch on boards with a different development, because
    using different element base can lead to the base frequency shifts, respectively error receiving / transmitting occur more frequently. On the development board electronic components is the same so I barely caught the problem.
  • 0 in reply to Ilya Volkov
    TI__Genius 9180 points
    That's good to know thanks. If you have not tuned the antenna on your HW then this could lead to more Rx errors and the issue could be related to this. I'll try running the tests on CC1310DK without the antenna attached and with and some distance to simulate your setup.

    Regards,
    TC.
  • 0 in reply to TopCat
    Intellectual 260 points

    Although there can be problems in the radio path, the program shall not hang.

    I have modified the rfWsnConcentrator project at "ConcentratorRadioTask.c" file as shown below and it worked for a day without hangs. But I doubt that this is the correct solution.

    static void rxDoneCallback(EasyLink_RxPacket * rxPacket, EasyLink_Status status)
{
   union ConcentratorPacket* tmpRxPacket;

   /* If we received a packet successfully */
   if (status == EasyLink_Status_Success)
   {
       ...
   }
   else
   {
       Event_post(radioOperationEventHandle, RADIO_EVENT_INVALID_PACKET_RECEIVED);
   }
}

    For rfWsnNode project, i have not found the decisions, only can understand where it hangs. It occurs because EasyLink_transmit function can not pend semaphore and returns EasyLink_Status_Busy_Error value, respectively the program goes to System_abort.

  • 0 in reply to Ilya Volkov
    TI__Genius 9180 points

    I totally agree, it should not hang. The issue is caused by the RX errors and should have been picked up during our testing before the example was released.

    I also found the same fix last night for the rfWsnConcentrator example; in that an RX is not re-scheduled if an RX error happens, causing the system to lockup. As you mentioned you need the following fix to the rfWsnConcentrator example in ConcentratorRadioTack.c:

    static void rxDoneCallback(EasyLink_RxPacket * rxPacket, EasyLink_Status status)
{
    union ConcentratorPacket* tmpRxPacket;

    /* If we received a packet successfully */
    if (status == EasyLink_Status_Success)
    {
        /* Save the latest RSSI, which is later sent to the receive callback */
        latestRssi = (int8_t)rxPacket->rssi;

        /* Check that this is a valid packet */
        tmpRxPacket = (union ConcentratorPacket*)(rxPacket->payload);

        /* If this is a known packet */
        if(tmpRxPacket->header.packetType == RADIO_PACKET_TYPE_ADC_SENSOR_PACKET) {
            /* Save packet */
            memcpy((void*)&latestRxPacket, &rxPacket->payload, sizeof(struct AdcSensorPacket));

            /* Signal packet received */
            Event_post(radioOperationEventHandle, RADIO_EVENT_VALID_PACKET_RECEIVED);
        }
        else {
            /* Signal invalid packet received */
            Event_post(radioOperationEventHandle, RADIO_EVENT_INVALID_PACKET_RECEIVED);
        }
    }
    else {
        /* Signal invalid packet received */
        Event_post(radioOperationEventHandle, RADIO_EVENT_INVALID_PACKET_RECEIVED);
    }
}

    You should also remove the RF_EventRxAborted from the EASYLINK_RF_EVENT_MASK  in EasyLink.c for both the rfWsnNode and rfWsnConcentrator projects:

    #define EASYLINK_RF_EVENT_MASK  ( RF_EventLastCmdDone | RF_EventCmdError | \
             RF_EventCmdAborted | RF_EventCmdStopped | RF_EventCmdCancelled )

    Finally I did see an infrequent lookup in the RF driver. I can confirm that this does not happen in the latest TIRTOS internal release that is currently in test. This will be release (including the above fixes) within 1 week. I hope that is acceptable.

    Regards, TC. 

  • 0 in reply to TopCat
    Intellectual 260 points
    Of course it is acceptable, I'll wait new release.
    I am very glad that you were able to catch and fix the problem.
    Thank you very much.
  • 0 in reply to Ilya Volkov
    TI__Genius 9180 points
    The new release is available here:
    software-dl.ti.com/.../

    Please let me know if you still see the issue with this release.

    Regards, TC.
  • 0 in reply to TopCat
    Intellectual 260 points

    Unfortunately, I still see the issue with release 2_16_00_08.
    Just in case, the examples I have tried to re-create from new release.

    rfWsnNode - hangs.
    rfWsnConcentrator - works stable.

  • 0 in reply to Ilya Volkov
    TI__Genius 9180 points

    I have just tested on the 2_16_00_08 release:

    I can no longer replicate the issue, please confirm that you also see this issue as resolved.

    Regards, TC.

  • 0 in reply to TopCat
    TI__Genius 9180 points
    Please verify that you have updated both the example and TIRTOS by installing the 2_16_00_08 and re-importing the example. From the attached project I see that your custom_argvars are still pointing at tirtos_cc13xx_cc26xx_2_15_00_17.

    Regards, TC.
  • 0 in reply to TopCat
    Intellectual 260 points

    I have not used my old examples.
    This is the steps that I have done:
    1. Using the uninstaller I deleted 2_15_00_17 (c:\ti\tirtos_cc13xx_cc26xx_2_15_00_17\uninstall.exe);
    2. Install the new release (tirtos_cc13xx_cc26xx_setupwin32_2_16_00_08.exe);
    3. Create a new directory and imported there examples;

    Therefore, guaranteed that the examples created on new release.

    20160301_projects.zip

  • 0 in reply to Ilya Volkov
    TI__Genius 9180 points

    I think I have found the issue in EasyLink.c. Throughout this file it is assumed that the RF_CmdHandle asyncCmdHndl is != 0 for a valid handle. However it is an int16 that uses -1 as invalid, and it can wrap around to 0, so this was an invalid assumption. If asyncCmdHndl from Rx command is 0 and the acknowledgement packet is lost/corrupted the call to EasyLink_abort will not abort the RX, as a result the next Tx will return a EasyLink_Status_Busy_Error and the System_abort will be called to trap the error. In your test case this is exactly what seems to be happening. To fix this issue you should change the code shown below in EasyLink.c:

    EasyLink_Status EasyLink_abort(void)
{
    EasyLink_Status status = EasyLink_Status_Cmd_Error;

    if(!configured)
    {
        return EasyLink_Status_Config_Error;
    }
    //check an Async command is running, if not return success
    //if(asyncCmdHndl == NULL)
    if(asyncCmdHndl < 0)
    {
        return EasyLink_Status_Success;
    }

    Regards, TC.

  • 0 in reply to TopCat
    Intellectual 260 points

    Sorry for the delayed response.
    I tried to fix: "if(asyncCmdHndl < 0)", but after first receive ack from concentrator, node is hangs.
    Then I modified this condition: "if(asyncCmdHndl <= 0)", but node still hangs.

  • 0 in reply to Ilya Volkov
    TI__Guru 56650 points

    Hi,

    I just tested the RF WSN examples from the TI-RTOS SimpleLink v2.16.00.08 myself, and I can't reproduce the issue. I am using CC1310DK with SmartRF06EB and made the changes you described on E2E. I changed the RF settings a bit, and use custom phy:

    #define RADIO_EASYLINK_MODULATION EasyLink_Phy_Custom

    in RadioProtocol.h by changing the sync bytes in order to be able to sniff the packets using SmartRF Packet Sniffer: http://www.ti.com/tool/packet-sniffer and CC1111 USB dongle. 

    Below you can see the screenshot I did with the SmartRF Packet Sniffer:

    as you can see above I managed to see both nodes to exchange up to almost 100.000 packets without problem, and I still have the nodes running after more than 15 minutes.

    Is there any other modification you made besides the one on  nodeTaskFunction() function?

  • 0 in reply to Ilya Volkov
    TI__Genius 9180 points
    Sorry for the delay, I have been traveling. The full list of changes required are below:

    @@ -200,22 +200,22 @@
    static uint8_t addrFilterTable[EASYLINK_MAX_ADDR_FILTERS * EASYLINK_MAX_ADDR_SIZE] = {0xaa};

    //Mutex for locking the RF driver resource
    static Semaphore_Handle busyMutex;

    //Handle for last Async command, which is needed by EasyLink_abort
    -static RF_CmdHandle asyncCmdHndl = NULL;
    +static RF_CmdHandle asyncCmdHndl = -1;

    //Callback for Async Tx complete
    static void txDoneCallback(RF_Handle h, RF_CmdHandle ch, RF_EventMask e)
    {
    EasyLink_Status status;

    //Release now so user callback can call EasyLink API's
    Semaphore_post(busyMutex);
    - asyncCmdHndl = NULL;
    + asyncCmdHndl = -1;

    if(e & RF_EventLastCmdDone)
    {
    status = EasyLink_Status_Success;
    }
    else if( (e & RF_EventCmdAborted) || (e & RF_EventCmdCancelled ) )
    @@ -242,13 +242,13 @@
    static EasyLink_RxPacket rxPacket;
    rfc_dataEntryGeneral_t *pDataEntry;
    pDataEntry = (rfc_dataEntryGeneral_t*) rxBuffer;

    //Release now so user callback can call EasyLink API's
    Semaphore_post(busyMutex);
    - asyncCmdHndl = NULL;
    + asyncCmdHndl = -1;

    if (e & RF_EventLastCmdDone)
    {
    while(pDataEntry->status != DATA_ENTRY_FINISHED);

    if( (rxStatistics.nRxOk == 1) ||
    @@ -292,13 +292,13 @@
    }

    //Callback for Async TX Test mode
    static void asyncCmdCallback(RF_Handle h, RF_CmdHandle ch, RF_EventMask e)
    {
    Semaphore_post(busyMutex);
    - asyncCmdHndl = NULL;
    + asyncCmdHndl = -1;
    }

    static EasyLink_Status enableTestMode(EasyLink_CtrlOption mode)
    {
    EasyLink_Status status = EasyLink_Status_Cmd_Error;
    //This needs to be static as it is used by the RF driver and Modem after
    @@ -720,13 +720,13 @@
    //Check if not configure or already an Async command being performed
    if(!configured)
    {
    return EasyLink_Status_Config_Error;
    }
    //Check and take the busyMutex
    - if( (Semaphore_pend(busyMutex, 0) == FALSE) || (asyncCmdHndl != NULL) )
    + if( (Semaphore_pend(busyMutex, 0) == FALSE) || (asyncCmdHndl > 0) )
    {
    return EasyLink_Status_Busy_Error;
    }
    if(txPacket->len > EASYLINK_MAX_DATA_LENGTH)
    {
    return EasyLink_Status_Param_Error;
    @@ -894,13 +894,13 @@
    //Check if not configure of already an Async command being performed
    if(!configured)
    {
    return EasyLink_Status_Config_Error;
    }
    //Check and take the busyMutex
    - if( (Semaphore_pend(busyMutex, 0) == FALSE) || (asyncCmdHndl != NULL) )
    + if( (Semaphore_pend(busyMutex, 0) == FALSE) || (asyncCmdHndl > 0) )
    {
    return EasyLink_Status_Busy_Error;
    }

    rxCb = cb;

    @@ -952,13 +952,13 @@

    if(!configured)
    {
    return EasyLink_Status_Config_Error;
    }
    //check an Async command is running, if not return success
    - if(asyncCmdHndl == NULL)
    + if(asyncCmdHndl < 0)
    {
    return EasyLink_Status_Success;
    }

    //force abort (gracefull param set to 0)
    if(RF_cancelCmd(rfHandle, asyncCmdHndl, 0) == RF_StatSuccess)

    Regards,
    TC.
  • 0 in reply to Leo Hendrawan
    Intellectual 260 points
    I made only one change on nodeTaskFunction() function, which is described in the topic.
  • 0 in reply to TopCat
    Intellectual 260 points
    I applied all the data change and at first glance - it helped. The system worked for an hour without any hang-ups! The near future, I will continue testing for 1-2 days continuously
  • 0 in reply to Ilya Volkov
    Prodigy 245 points

    I also found this problem，rfWsnNode example run minutes will  hangs

    TI-RTOS VERSION :2.16.00.08

  • 0 in reply to TopCat
    Expert 1435 points
    Made changes as TopCat list, still not run rxDoneCallback......and the busyMutex can't be released, so I always got a EasyLink_Status_Busy_Error...... I want to cry.......>_<..........
  • 0 in reply to TopCat
    Expert 1435 points
    In my occasion, I found that asyncCmdHndl from Rx command (EasyLink_cmdPropRxAdv) is 2, not 0, acturally in the raw logic it is a valid handle, but why it is still cannot call rxDoneCallback, so busyMutex can't be released, so I always got a EasyLink_Status_Busy_Error . Can you help me?? I have spent several days on this problem. I will appreciate to have your reply.
  • 0 in reply to Jing Xia
    TI__Genius 9180 points

    Can you please give some more details:

    How long is the system running before yo see the issue?

    Is the signal strength poor?

    How fast are you sending messages?

    Regards,
    TC.

  • 0 in reply to TopCat
    Expert 1435 points

    TI-RTOS : 2_16_00_08

    CCS  Version: 6.1.2.00015

    I use a clock to triggle a transmit or receive operation, depending on whether there has data to be send,  every 100ms.

    I used a semaphore and the RX timeout was set to 70ms, and it ran without hang . But I try to add a EasyLink_setFrequency operation today  and it hang again!!!  Actually the EasyLink_setFrequency operation success, and  the value of asyncCmdHndl which  RF_postCmd(rfHandle, (RF_Op*)&EasyLink_cmdPropRxAdv,
                RF_PriorityNormal, rxDoneCallback, EASYLINK_RF_EVENT_MASK) returns is 3, but I don't know why the system stuck.

  • 0 in reply to Jing Xia
    TI__Genius 9180 points
    There is a known issue when asyncCmdHndl wraps around to 0. Can you check if you see the issue when asyncCmdHndl = 0? This issue will be fixed in the next TIRTOS release.
  • 0 in reply to Ilya Volkov
    Prodigy 220 points
    Hi Volkov,

    did u get solution for the above issue ? i am using CC1310 chip to use ZigBee Communication , first of all i am not able to see basic communication.

    i am trying to prove that hardware is working or by using RF Transmiter Tool to send packets and receive same packet in another RF Trnasmiter Tool.

    is the above method is correct ? what setting that i should do to work ?

    the same setup with CC2650 ( BLE and 802.14 modes ) working fine.

    Can you please hellp me , is there any Basic code example , where i can load into my board by compiling in CCS IDE ?

    appreciate your quick help.


    Ramesh Gorrepotu
  • 0 in reply to RameshG
    TI__Genius 9180 points

    Ramesh,

        Having RF communication on CC1310 is provided with any of the RF examples provided for CC1310, see: (Sub1G + BLE examples on CC1350 dual mode device is also here). An simple example of basic communication is provided in rfPacketTx/Rx. You can also use the windows graphical SmartRF Studio tool to send/receive packets with the CC1310.

    The issues in this thread have been resolved in previous TIRTOS release. The Wsn Example released in the next release will also use Rx Timeouts instead of Rx aborts to make it easier to understand the code. 

    However your thread seems completely unrelated and refers to running ZigBee on the CC1310 (Sub1G) which is not support. Our ZigBee stack is provided on CC2530, CC2538 and CC2630 (2.4G devices). The Z-Stack MAC layer is 2.4G and will not run on a Sub1G devices. Porting ZigBee to Sub1G is not an easy undertaking and would require porting the Zigbee stack to a  Sub1G MAC.

    RameshG said:
    the same setup with CC2650 ( BLE and 802.14 modes ) working fine.

    Do I understand correctly that you expect to run BLE and TIMAC CC2650 SW (2.4G) on a CC1310 (Sub1G) device? For above reasons this will never work, for a start they are different frequency bands. The CC1350 is now supported in the BLE stack, but this is because it supports 2.4G band (as well as Sub1G). 

    Regards,

    TC.