Hi Logan,

Which version of the SIMPLELINK-CC13XX-CC26XX-SDK are you using, and which TI-OpenThread examples are being evaluated?  Please provide details for both the client and server configurations, as well as any changes which were made to the default project settings.

Regards,
Ryan

Hi Ryan,
Thank you very much for your time.
I am using simplelink_cc13xx_cc26xx_sdk_6_40_00_13.

Initial functionality testing using 2 examples:
------------------------------------------------------------
1. door_lock_LP_CC2652R7_tirtos7_gcc (Default: Running as the Coap server)
2. cli_ftd_CC2652R7_tirtos7_gcc (Default: Setting up the thread network and running as the Coap client)


Steps Followed:
---------------------
1. Extraction of the Coap server functionality from the door_lock example.
2. Extraction of the Coap client functionality from the cli_ftd example.
3. Integration of the Coap client into the door_lock example. [Coap server removed]
4. Integration of the Coap server into the cli_ftd example.   [Coap client not used]


Naming Convention:
--------------------------
1. Device     -> door_lock example running the Coap client code.
2. Controller -> cli_ftd example running the thread network and Coap server code.


System Setup: (Device & Controller)
-------------------
1. The Controller sets up the thread network and start the Coap server. [1 server resource only]
2. The Device is commissioned onto the Controller thread network.
3. The Device initiates COAP get requests to the Controller (Coap server) every 2 seconds


Message model of COAP GET requests:
------------------------------------------------------
1. Device initializes a confirmable COAP GET request message. Prior to transmission, data is appended to this Coap message.
(e.g {"data_1": 20120010, "data_2": "some string information", "data_3": "some string information"} )

2. Controller receives the data and replies with a message to that specific device.
(e.g {"device_1_data_1": 20120010, "device_1_data_2": "some string information", "device_1_data_3": "some string information"} )


If you require more information, please do let me know.

Kind regards,
Logan Becker

Thank you for the full description of your setup.

Logan Becker said:

Integration of the Coap client into the door_lock example. [Coap server removed]

Can you please explain the reasoning behind this decision?  TI does not support the door_lock example as a Coap client given that this orientation is not sensical for Thread applications.  There could be configuration issues based on the migration process.  Holistically the recommendation is to evaluate Matter over Thread for such application endeavors.  Please determine whether this E2E thread is relevant.

Regards,
Ryan

Hi, Ryan,

The example can be found inside simplelink_cc13xx_cc26xx_sdk_6_40_00_13/examples/rtos/LP_CC2652R7/thread/door_lock

Inside the doorlock.c file you will find Coap server functions to which I am referring to.
Although, the door_lock example does not function as a coap client. I have implemented it to function as a coap client and thus far works for 2 devices already connected to the server.

Matter over Thread has been experimented with before, but due to complexities and the requirement of an embedded linux processor this is too expensive. We have kept it for use latter down the line. We have a tight deadline to deliver products in a few months.

Kind regards,
Logan Becker

Yes, we are agreed that the door_lock example is a Coap server by default.  Why does it need to function as a Coap client?  That implementation is not consistent with the application usage and it makes more sense to use a CLI FTD as Coap client instead (note the CLI can be either implementation). 

The Thread stack offering is being simplified as it further integrates with the Matter solution.  TI's next update of the stack will likely not include application examples (like door_lock) as Matter is expected to fill this role.  Have you considered Zigbee?  It is also a long-standing mesh networking solution which has an established application layer (i.e. the Zigbee Cluster Library, or ZCL) and can connect to IoT using a Zigbee Gateway.

Regards,
Ryan

Hi Ryan,

It is per specification that it has been implemented in this fashion.
Thank you for the heads up. This will be considered later on.
The issue that has been causing much problems with coap messaging has been pinpointed to:
error = otMessageAppend(message, data, strlen(data));
The error returns OT_ERROR_NO_BUFS
An attempt to call otMessageFree(message) to handle mentioned error,
blocks the code inside coap.cpp in the method at OT_ASSERT:

void ResponsesQueue::ResponseMetadata::ReadFrom(const Message &aMessage)
{
    uint16_t length = aMessage.GetLength();

    OT_ASSERT(length >= sizeof(*this));
    IgnoreError(aMessage.Read(length - sizeof(*this), *this));
}

I do hope you may have useful information to resolve such as issue.
Perhaps a method to handle and prevent the growth of message buffers
that lead to this problem.

Kind regards,
Logan Becker

This is a great debug step and I would encourage you to breakpoint at this error to further understand the call stack and variables.  You will find in radio.c that OT_ERROR_NO_BUFS is typically associated with rfCoreFindEmptyShortSrcMatchIdx or otPlatRadioAddSrcMatchExtEntry not finding an empty entry, either during otPlatRadioAddSrcMatchShortEntry or otPlatRadioAddSrcMatchExtEntry respectively.  You could try to increase the number of short/extended addresses, PLATFORM_RADIO_SHORTADD_SRC_MATCH_NUM and PLATFORM_RADIO_EXTADD_SRC_MATCH_NUM in radio.h, or factory reset.  However I believe that not so many devices are joining the network and thus you need to determine how to clear unused entries, otPlatRadioClearSrcMatchShortEntries and otPlatRadioClearSrcMatchExtEntries, from your application.

Regards,
Ryan