Add TI CC13x2 and CC13x4 device support

[pradeep-hn]

PR Overview: TI SimpleLink Wi-SUN FAN Platform Support

This PR adds support for TI's CC13xx/CC26xx microcontrollers (running a Wi-SUN FAN mesh network) as a new target platform for csmp-agent-lib.

New Files / Key Additions:

osal/ti_simplelink_wisun/

• New OS Abstraction Layer wiring the library's socket, thread, mutex, timer, and storage APIs to FreeRTOS and the vendor networking stack.
• A compile guard prevents a duplicate main() symbol when the library is linked into our firmware that already defines its own main().

sample/tlvs/ti_simplelink_wisun_tlvs.c

• Platform-specific TLV callbacks: network status, routing data, interface metrics, firmware version, and hardware description.

Vendors/TI/application/

• Router node application: joins the mesh, opens a UDP socket to the NMS, starts the CSMP agent.
• Includes RF/PHY config for 915 MHz North America and mesh auth certificates.
• sntp_sync.c/.h: lightweight NTP client that syncs time right after mesh join. Falls back to a compile-time epoch if the server is unreachable (needed for accurate OTA scheduling).

tools/tpd_config_cc13xx.json

• Config for wrapping the signed firmware binary before uploading to the management server for OTA.

Vendors/TI/README.md

• Full setup guide: network architecture, build steps, device provisioning, flashing, IPv6 routing, NTP setup, and OTA upgrade walkthrough.

Vendors/TI/OpenCSMP_01.00_manifest.html

• Open-source manifest required for public release.

Board Support

5 LaunchPad variants supported (LP_CC1312R7, LP_CC1352P7_1, LP_EM_CC1314R10, LP_EM_CC1354P10_1, LP_EM_CC1354P10_6). Each board only carries its own config and compiler flags; all application code is shared.

The entire networking stack comes from TI simplelink sdk.

Build System

• build.sh ti_simplelink_wisun builds all 5 boards in one command.
• Root Makefile defaults the platform to SECUREBOOT so the signed firmware binary is always produced.
• Firmware is signed via MCUBoot; version stamp is auto-generated from build date so no manual bumps are needed between OTA cycles.
• Heap and timer stack sizes increased across all board configs to accommodate SNTP and OTA memory usage.

Changes to Existing Shared Files

osal/osal.h Added TI spcific defines
include/iana_pen.h Added vendor IANA PEN entry
sample/CsmpAgentLib_sample.c Added #ifdef guard around main()
sample/Makefile Added clean target for the new platform
src/coap/coapclient.c Minor fix
Makefile / build.sh Added new platform target and entry

Here is the summary of the test results, grouped by functional area:

• Device Registration & Inventory: Verified that freshly flashed devices successfully join the Wi-SUN network, register with the FND, and appear in the inventory with correct metadata and an "up" status.
• Metrics Reporting & Stability: Confirmed that devices reliably report periodic CSMP and Wi-SUN-specific metrics (such as WpanStatus and InterfaceMetrics) without drops, maintaining stable connectivity during a 24-hour soak test.
• Firmware Information Accuracy: Validated that the FND correctly reads and displays the current running firmware version and slot table data before any OTA processes begin.
• OTA Transfer & Activation: Successfully tested full OTA cycles, ensuring all 1060 blocks are received and validated, followed by successful device reboots and version updates in the FND.
• OTA Resilience & Recovery: Verified system robustness through mid-download power cycles (resuming from missing blocks), superseding pending activations with new versions, and performing 10 consecutive stress cycles.
• Multi-Device Scalability: Demonstrated that the FND and border router can handle simultaneous OTA updates and concurrent metric reporting from multiple devices without interference or registration failures.

[silabs-ThibautC]

@manojnacsl At some point we'll need to rework that file. We cannot have vendor specific defines in that file.

It would probably make sense to move the main function (among others TBD) to a vendor specific folder of the sample application.

[silabs-ThibautC]

@manojnacsl We should probably consider moving those vendor specific defines in another file.

[manojnacsl]

CoAP responses clip tokens and payloads.
osal_sendmsg() sends only msg_iov[0], while the server constructs up to four iovecs for the CoAP header, token, payload marker, and body. Normal responses are therefore truncated or malformed.
Flatten the buffers or handle iovec before sending.
osal_ti_simplelink_wisun.c#L305-L315
coapserver.c#L151-L202

[ti-aryan]

I have fixed this by flattening the msg_iov entries into a single contiguous buffer before calling osal_sendto(). I’ve also bounded this buffer to 1280 bytes (matching our existing RX buffer size) to ensure safety. Thank you for the precise line references

[manojnacsl]

Please elaborate and clarify why SetBackupRequest is accepted but ignored (no-op). Isn't the image to be backed-up be written onto a persistent storage(flash) for later recovery?
A LoadRequest from backup storage slot would load this image onto the active run slot.

Either implement backup-slot storage/activation through MCUboot or reject/disable backup operations for this platform.

[ti-aryan]

Thank you for spelling out that risk so clearly. On reflection, you are right, allowing a "silent success" could lead to a corrupted BACKUP_IMAGE slot, potentially bricking the device.

Since this platform currently lacks dedicated physical storage for a backup slot, I have implemented your alternative suggestion: osal_copy_firmware() now returns a failure when BACKUP_IMAGE is involved. This ensures SetBackupRequest is correctly rejected with RESPONSE_INVALID_REQ

[manojnacsl]

Thanks for addressing this - osal_copy_firmware() now rejects unsupported backup operations.

However, the previous false-success path for SetBackupRequest is partly fixed - sample_data_init() still initializes the upload and backup headers by copying the running-image header, marking nonexistent images as complete. That can cause FND to see erased slots as valid firmware. CsmpAgentLib_sample.c#L89-L105

We'll need to review and handle this scenario.

[ti-aryan]

As a short-term fix, we can patch application.c to clear those slots back to empty/incomplete right after sample_data_init() if they still match the running image's hash. A complete fix would be in CsmpAgentLib_sample.c itself zeroing the slot and marking it FWHDR_STATUS_DOWNLOAD in the fallback branch instead of copying the running image's header which would fix this for all platforms hitting that path

[manojnacsl]

Suggested change

	#define VENDOR_ID TI

Vendor ID to be changed to TI

[manojnacsl]

Please add a detailed PR description capturing the overall changes for TI platform integration, development/build toolchain used, testing performed, known caveats if any. Thanks.

[manojnacsl]

@ti-aryan @pradeep-hn - There have been recent commits to CiscoDevNet:main by Renesas and Cisco.

Suggest that you update/sync TexasInstruments:main_ti fork to latest CiscoDevNet:main and push the updated code to PR61 to ensure you are working your changes on top of the latest repo.

11 commits behind CiscoDevNet:main : TexasInstruments/csmp-agent-lib@main_ti...CiscoDevNet:csmp-agent-lib:main

[manojnacsl]

Socket-close abstraction seems broken
The PR replaces osal_socket_close() with raw close():

• coapclient.c#L45-L50
• coapserver.c#L45-L50
• coapserver.c#L77-L81
  On TI, the handle is a Nanostack socket, not a POSIX descriptor:
• osal_socket() returns socket_open() for the server.
• The client receives a synthetic handle equal to g_ns_sock + 64.
• close() cannot correctly close either handle, especially the synthetic client handle.
• g_sock_alloc_count is never reset, so reopening after a stop will not call socket_open() again.

The TI OSAL should implement osal_socket_close() using Nanostack’s socket_close(), reset the socket/channel state, and the common CoAP code should retain the OSAL abstraction.

[ti-aryan]

Same root cause as the other comment our PR predated upstream's osal_socket_close() abstraction, so our OSAL still had raw close() calls and no TI implementation. We've since rebased onto the latest upstream and implemented osal_socket_close() for the TI platform using Nanostack's socket_close(), with per-channel state tracking so the server and client channels can open/close independently and correctly reopen via socket_open() afterward. Should be resolved now.

[manojnacsl]

External receive-task/API regression issue to be reviewed
The main branch supports USE_EXTERNAL_RECV_TASKS by:

• Not creating an internal receive task when the macro is defined.
• Exposing coapclient_process_response() and coapserver_process_datagram() for the application to call.
• Closing sockets through osal_socket_close().
  The updated PR still removes that behavior:
• coapclient_open() always creates recv_fn; coapserver_listen() always creates recv_thread.
• The receive functions always call the private-renamed process_response() / process_datagram().
• The public processing functions are removed from both headers.
• coapclient_stop() and coapserver_stop() unconditionally cancel recvt_id_task.
  Relevant code:
• coapclient.c#L42-L79
• coapserver.c#L31-L92
• coapclient.c#L240-L275
• coapserver.c#L95-L132

This breaks existing users that define USE_EXTERNAL_RECV_TASKS: their application receiver and the newly created internal receiver will race for packets, and existing calls to the public processing APIs will no longer compile.

[ti-aryan]

Our PR was originally based on an older upstream revision, before USE_EXTERNAL_RECV_TASKS support, the public coapclient_process_response()/coapserver_process_datagram() APIs, and the osal_socket_close() abstraction were added to main. We've since rebased onto the latest upstream and pulled in all of that verified our coapclient.c/coapserver.c/headers now match main exactly on this behavior. Should be resolved on our side now.