• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Subscribers 55 subscribers
  • Views 1070 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

LAUNCHXL-CC26X2R1: Thermostat CoAP stops updating temperature data

Austin Hellenbrand1
Prodigy 50 points
Part Number: LAUNCHXL-CC26X2R1


Hello,

While experimenting with the TI-Thread Thermostat and Temperature Sensor example projects on the LaunchXL-CC26X2R1 platform, the thermostat CoAP appears to stop receiving updated temperature readings from the temp. sensor. 

Once both devices have joined the network, the thermostat will stop receiving  Temp change events from the CoAP. Once the network is established, the CUI is updated a total of 40 times before it stops updating. 

Using a 3rd board with the CLI project, I can request the temperature from the thermostat (thermostat/temperature), but it is the stale value shown on the CUI. 

Could someone share some insight into this problem? 

I am using the following:

SDK: 4.30.0.54

CCS: 10.0.0.00010

Thank you, 

  • 0
    TI__Mastermind 35070 points

    Hi,

    Thank you for reporting this.

    It seems related to a known issue (TIOP-954): 

    Can you share a sniffer log which contains the issue ?

    Austin Hellenbrand1 said:
    Using a 3rd board with the CLI project, I can request the temperature from the thermostat (thermostat/temperature), but it is the stale value shown on the CUI. 

    Can you try requesting temperature from the tempsensor (tempsensor/temperature) from the CLI also ?

    Regards,
    Toby

  • 0 in reply to Toby
    Prodigy 50 points

    That issue certainly appears to be what I am experiencing. 

    Are you referring to a log from the Smart RF Sniffer Agent or a Wireshark capture? I will try and get a capture tomorrow and post it. 

    When the Thermostat is a router and the CLI is the leader, I can request the temperature from both the Thermostat and Temp Sensor. But when the Thermostat is the leader and the CLI is a router, I only receive a reply from the Thermostat sometimes. 

    Regards, 

    Austin

  • 0 in reply to Austin Hellenbrand1
    Prodigy 50 points

    Hi,

    Here is a Wireshark capture of the issue.

    Thermostat_Tempsensor_capture.zip Wireshark doesn't save marked packets, but I added comments on a few to mark certain points. I reset the Thermostat at packet number 412, following the link re-establishment the Thermostat begins to update its temperature. I have comments on every 10th packet up to the 50th packet. Packet 41 is where the Thermostat appears to stop accepting updated temperature data. 

    There doesn't seem to be a difference between the accepted and unaccepted packets that I can see.

    Regards,

    Austin

  • 0 in reply to Austin Hellenbrand1
    TI__Mastermind 35070 points

    Thanks for sharing the log.
    I don't immediately see any issue.

    I'll investigate and get back to you in a few days.

  • 0 in reply to Austin Hellenbrand1
    TI__Mastermind 35070 points

    It seems that I have re-created the issue. I created a network with CLI, then joined the Tempsensor and Thermostat.
    After leaving the network to run overnight, I see that the Thermostat is no longer updating with latest reported values from TempSensor.

    The Thermostat is still sending advertisements, but did not promote to leader (I kept the CLI leader in the network).
    So I believe this is likely related more to the CoAP side of things.

    Did you have the debugger connected to the Thermostat when the issue occurs? I'd be interested to see if coapHandleTemp is triggered after the Thermostat stops updating.

  • 0 in reply to Toby
    Prodigy 50 points

    I have used the debugger to the Thermostat example and the coapHandleTemp is never triggered after the Thermostat stops updating. 

    I made an additional discovery that seems to point towards the CoAP side as well. If the TempSensor example is modified to send a Confirmable message, the Thermostat does not enter the failure state and will continue to update. However, I would like to use non-confirmable messages for my end design. 

    Thanks for you continued assistance,

    Austin 

  • 0 in reply to Austin Hellenbrand1
    TI__Mastermind 35070 points

    Hi Austin,

    Happy new year!

    Thanks for the additional info, that the issue does not happen after switching to Confirmable messages.

    I'll need to debug a bit further, such as:

    - does having two registered CoAP resources append to the issue ?
    - can we shorten the time frame in which the issue occurs, by shortening the period between temp_sensor broadcasts ?

    I'll continue investigation and get back to you in a few days.

    Regards,
    Toby

  • 0 in reply to Austin Hellenbrand1
    TI__Mastermind 35070 points

    An update from our side.

    After some further debugging, I believe the root cause is a out-of-buffer issue.

    When non-confirmable messages are used, the function coapHandleTemp ends up not freeing the responseMessage.
    When confirmable messages are used, the responseMessage is always freed (either by coapHandleTemp function itself, or within the Thread stack).

    To fix this issue, try the following code change in coapHandleTemp:

            if (OT_COAP_TYPE_CONFIRMABLE == messageType)
        {
            error = otMessageAppend(responseMessage, thermostatTemp,
                                    strlen((const char*)thermostatTemp));
            otEXPECT(OT_ERROR_NONE == error);

            error = otCoapSendResponse((otInstance*)aContext,
                                       responseMessage, aMessageInfo);
            otEXPECT(OT_ERROR_NONE == error);
        }
        // toby added, to free for non-con message
        else if (OT_COAP_TYPE_NON_CONFIRMABLE == messageType && responseMessage != NULL)
        {
            otMessageFree(responseMessage);
            responseMessage = NULL;
        }
        // end added

    This change seems to resolve the issue on my end, please let us know if you run into any issues with this.

    Regards,
    Toby

  • 0 in reply to Toby
    Prodigy 50 points

    Toby, 

    Thanks for the continued support on this issue. The Thermostat now updates continuously as expected.

    One question regarding the solution. Does the Thread stack mutex need to be locked (using OtRtosApi_lock() and OtRtosApi_unlock()) before calling otMessageFree(responseMessage)? I see that it is not locked in the Exit error section in the Thermostat code but, in the Exit error section of the TempSensorReport function in the Temp Sensor code, it is locked before freeing the request message.

    Regards,

    Austin

  • 0 in reply to Austin Hellenbrand1
    TI__Mastermind 35070 points

    Thanks for confirming that the Thermostat works now!

    Good catch on the mutex.
    In general I do recommend calling lock/unlock before/after any openthread API usage.

    However, coapHandleTemp (and coapHandleSetPt) is called from the stack task to handle it, so the mutex lock should've occurred by the time coapHandleTemp is entered.