https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/<p style="display:none;">blank</p>en-USTelligent Community 13https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1686193/cc2340r5-some-question-of-zboss-in-simplelink_lowpower_f3_sdk_9_21_00_36_lts/6498179Wed, 30 Sep 2026 08:31:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:4e56f835-90cc-4172-ae72-7fb633682875Aries LordI would like to increase the timeout period for ZDP Response. Meanwhile, I want to reduce the retransmission interval when APS Retry is enabled. It would even be acceptable to terminate the waiting for ZDP Response in advance once APS Confirm indicates that the ZDP Request transmission has failed. Is it possible to directly disable APS Retry for ZDP Requests?https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1686193/cc2340r5-some-question-of-zboss-in-simplelink_lowpower_f3_sdk_9_21_00_36_ltsWed, 30 Sep 2026 08:26:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:d0f26762-dbbb-44cf-890f-a75e07cc04a9Aries LordPart Number: CC2340R5 I have three questions regarding ZBOSS Zigbee stack behavior on CC2340R5 with simplelink_lowpower_f3_sdk_9_21_00_36_LTS: The maximum timeout for ZDP Response is only 10 seconds. However, APS Retry is enabled for ZDP requests. With APS Retry turned on, the actual total timeout can reach up to 1 minute. This results in a situation where the ZDP Response reports a timeout, while the APS layer is still re‑transmitting the original ZDP Request command. Is it possible to suppress the Default Response for ZCL Attribute Report? Since APS Retry is already enabled for ZCL Attribute Report frames, receiving the Default Response is unnecessary for our use‑case. Our application needs to switch between Coordinator and Router operating modes. We store the mode configuration in NVRAM APP1. During the ZB_ZDO_SIGNAL_SKIP_STARTUP signal, we read the stored data from NVRAM APP1 and decide whether to start the stack as a Coordinator or a Router. When starting as a Coordinator, we call zboss_start_continue() to form a Coordinator network. When other Routers or End‑Devices join this network and read the Coordinator’s Node Descriptor, the returned ZDO Node Descriptor Response contains all‑zero fields. After the Coordinator device is reset / rebooted, the ZDO Node Descriptor Response returns correct expected values again. Any insights or workarounds would be appreciated.CC2340R5https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1682759/cc2652r-rx-fails-using-ti-simplelink-sdk-8-30-01-01/6496810Tue, 29 Sep 2026 07:02:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:6017a9b8-17a8-41c4-8986-5a3b2028a2ecMartin MeierHi Daniel, I setup a test as per your suggestion where macTask.c taken from 8.31 is placed in our 8.30 CCS project folder, and the locationURI in .project-file is modified to reflect the project location for macTask.c. Unfortunately the problem persist, i.e. the stack stops responding. Not sure what this gives us in terms of confirming the issue? However, we are quite confident that the upgrade to 8.31 solves the problem. I don&#39;t think we need to spend more time on this.https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1677452/cc2755p10-cc2755p10-availability-roadmap-of-zboss-ncp-sncp-device-side-build-for-cc23xx-cc27xx/6494413Fri, 25 Sep 2026 06:44:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:ef7192f0-cfe0-489d-8fa1-d26020e771d0Levent SagirogluHi Ging, Thank you — this is exactly what we needed to know. We will drop the custom coprocessor idea based on your recommendation, and start the conversation with our local FAE. Regards, Leventhttps://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1677452/cc2755p10-cc2755p10-availability-roadmap-of-zboss-ncp-sncp-device-side-build-for-cc23xx-cc27xx/6493729Thu, 24 Sep 2026 14:37:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:00ec1930-4d3d-4caa-a79e-475b6b488354Ging GonzalezHi Levent, Apologies for the delay. I have had discussions internally and found that both MAC-Split RCP and NCP support are in the plans. However, I don&#39;t have the exact timelines. For this, I recommend contacting your local Field Applications Engineer and starting a formal conversation with them. As for Item 5 in your original inquiry, you may be able to create your own messaging system between the host and a custom co-processor. You would just call ZBOSS APIs depending on your host messages and then respond back with status. However, I cannot recommend that you do this especially now that I know there are plans for NCP. Regards, Ginghttps://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1682759/cc2652r-rx-fails-using-ti-simplelink-sdk-8-30-01-01/6493666Thu, 24 Sep 2026 13:20:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:17bb3967-f961-4690-9a34-55d56a7247e2Martin MeierHi Daniel, Thanks. I have prepared the macTask to our test as you suggested. Will get back to you, hopefully within a few days, with a result. /Martinhttps://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1683592/cc2340r5-cc2340r5-both-zb_zdo_simple_desc_req-and-zb_zdo_active_ep_req-have-reported-timeouts-but-the-retransmission-is-still-continuing/6490175Mon, 21 Sep 2026 21:09:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:6ddffef3-5b40-4de5-93a5-0ea60b623ecdAlex FagerHello, Can you provide a log (sniffer log) of the packet activity if possible? Thanks, Alex Fhttps://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1682759/cc2652r-rx-fails-using-ti-simplelink-sdk-8-30-01-01/6489426Mon, 21 Sep 2026 10:44:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:9744b1cf-c5a9-4adf-b4ef-87a63e14c63fDaniel Guarecuco AguiarHi Martin, Ok, I don&#39;t have a way to easily replicated your issue. You could try to copy the macTask.c from the 8.31 SDK into your CCS project folder, copying it into the 8.30 SDK might not do anything as the project will use the precompiled lib .a \source\ti\ti154stack\common\osal_port\osal_port_posix\macTask.c Best regards, Danielhttps://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1682759/cc2652r-rx-fails-using-ti-simplelink-sdk-8-30-01-01/6489207Mon, 21 Sep 2026 06:48:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:72364ca8-022f-486a-9e47-c5574a7acb18Martin MeierHi Daniel, Thank you for reply. We want to confirm that the issue we are facing is indeed resolved in the 8.31 SDK. So far we have not seen the issue with the same setup with 8.31, but that&#39;s a vague confirmation. So the intention is to check with you to verify that the issue has been fixed in 8.31.https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1683592/cc2340r5-cc2340r5-both-zb_zdo_simple_desc_req-and-zb_zdo_active_ep_req-have-reported-timeouts-but-the-retransmission-is-still-continuing/6488261Fri, 18 Sep 2026 14:01:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:35e69fe0-3205-4d8f-849f-4c10009864f7Aries LordSDK is simplelink_lowpower_f3_sdk_9_21_00_36_LTS and simplelink_lowpower_f3_sdk_9_20_00_81https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1683592/cc2340r5-cc2340r5-both-zb_zdo_simple_desc_req-and-zb_zdo_active_ep_req-have-reported-timeouts-but-the-retransmission-is-still-continuingFri, 18 Sep 2026 13:59:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:29822223-1f1d-45e6-b7d9-272d2fe6810aAries LordPart Number: CC2340R5 The zb_zdo_simple_desc_req and zb_zdo_active_ep_req send requests to non-existent addresses, resulting in ZB_ZDP_STATUS_TIMEOUT after 10 seconds. The zb_af_set_zdo_data_conf_cb callback is received only after 56 seconds, reporting that no APS ACK has been received.CC2340R5https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1682759/cc2652r-rx-fails-using-ti-simplelink-sdk-8-30-01-01/6488191Fri, 18 Sep 2026 12:51:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:143bfa11-e45e-4cae-bae8-c81111ea58ecDaniel Guarecuco AguiarHi Martin, I&#39;m not quite sure. Not saying it is the same issue, but possible related. Maybe the energy scan hits a recover mechanism. Some other issues were fixed as documented in the release notes. What is the intention? Would you like to remain on SDK 8.30? Or is moving to 8.31 ok? Best regards, Danielhttps://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1682759/cc2652r-rx-fails-using-ti-simplelink-sdk-8-30-01-01/6486892Thu, 17 Sep 2026 13:00:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:9c696ba1-6604-4f53-b503-cee6d059234aMartin MeierHi Daniel, Ok, do you suggest that such memory corruption would recover by triggering a CCA energy detect scan?https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1682759/cc2652r-rx-fails-using-ti-simplelink-sdk-8-30-01-01/6486880Thu, 17 Sep 2026 12:48:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:8d377e94-80d8-4a0a-ba26-147b245b4043Daniel Guarecuco AguiarHi Martin, I can see that an issue (TI154STACK-4484) fixing a memory corruption in heap was fixed in version 8.31.00.11 TI 15.4-Stack 7.31.00.00 Release Notes . That was originally reported in the other thread CC2652R: DMM with BLE Peripheral + Ti15.4 Coordinator - how to send frames longer than 125 bytes - Zigbee &amp; Thread forum - Zigbee &amp; Thread - TI E2E support forums I think might be a related issue. Best regards, Danielhttps://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1682759/cc2652r-rx-fails-using-ti-simplelink-sdk-8-30-01-01/6486820Thu, 17 Sep 2026 11:36:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:c46fbc85-9a88-4c46-af7e-9875d9db45daMartin MeierHi Daniel, This is the same application as in the references thread. So, I am running a DMM, the device is setup as a coordinator on the network and I believe the example is taken from the ti154stack.https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1682759/cc2652r-rx-fails-using-ti-simplelink-sdk-8-30-01-01/6486783Thu, 17 Sep 2026 10:46:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:6de6e7ea-5564-488e-8f26-50fbcc4c95fdDaniel Guarecuco AguiarHi Martin, Are you referring to a Zigbee Coordinator or a TI 15.4-Stack Collector? Is the example taken from the zstack or ti154stack folder? I see you are linking to a DMM thread, are you running DMM? Best regards, Danielhttps://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1682759/cc2652r-rx-fails-using-ti-simplelink-sdk-8-30-01-01Wed, 16 Sep 2026 11:53:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:d515d35e-7851-4746-9f90-c030b6ae06d3Martin MeierPart Number: CC2652R Hello! We have encountered a problem with our application running as a TI15.4 Coordinator using TI Simplelink SDK 8.30.01.01 . In the current setup only one channel is configured, which means that no CCA measurements are being made. After ~30mins of quite heavy 15.4 traffic to the coordinator the stack stops responding. No callbacks are fired, it does not respond to UHF Scan. In this scenario, if I manually trigger a CCA (energy detect scan through ApiMac_mlmeScanReq) the stack recovers, meaning it responds to UHF scans, callbacks are fired on incoming messages and so on. Now, here&#39;s the interesting part: If I upgrade the application to TI Simplelink SDK 8.31.00.11 I can no longer reproduce the issue. This brings me to the question: Is this something you have discovered and fixed in 8.31.00.11? I can&#39;t find anyting in the 8.31.00.11 changelog that matches this behaviour.CC2652Rhttps://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1680390/cc2674p10-cc2674p10-zdsecmgr_tc_device_max-upper-limit/6483122Tue, 15 Sep 2026 02:14:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:b0038c55-2122-479a-ae91-c398bd2699b2jun caoAlex Fager : Thank you for your reply. I added &#39; #define NVOCMP_NVPAGES 10 &#39;, but the error in zigbee2mqtt remained the same. Initially, when NVOCMP_NVPAGES was at the default value of 5, zigbee2mqtt would throw an error after I changed ZDSECMGR_TC_DEVICE_MAX from 40 to 100. However, when I changed NVOCMP_NVPAGES from 5 to 10 and ZDSECMGR_TC_DEVICE_MAX from 40 to 100, zigbee2mqtt started successfully. I believe NVOCMP_NVPAGES determines the maximum value for ZDSECMGR_TC_DEVICE_MAX. Consequently, I changed NVOCMP_NVPAGES to 15 and ZDSECMGR_TC_DEVICE_MAX to 200, but this resulted in a compilation error. Could you please take a look at this?https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1680390/cc2674p10-cc2674p10-zdsecmgr_tc_device_max-upper-limit/6482852Mon, 14 Sep 2026 21:03:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:6ba968aa-9918-4b9f-9f5c-24c482c3ff9bAlex FagerHello jun cao, Thank you for sharing the document that showed how you modified the config, I took a quick look at this document to see if there could be something affecting the device and there was one section for now that we can try to modify. At around line 160 of the patch, I see the following below, we possibly need to also set this to 10 for the NVPAGES if you had not already in your process before. +#ifndef EM_CC2674P10_LP + #undef NVOCMP_NVPAGES + #define NVOCMP_NVPAGES 3 Thanks, Alex Fhttps://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1680390/cc2674p10-cc2674p10-zdsecmgr_tc_device_max-upper-limit/6481840Mon, 14 Sep 2026 03:07:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:4d7aefb7-6f70-4c12-9172-d12a766c1f1cjun caoHi Alex Fager : Simply compiling the ` znp_LP_EM_CC2674P10_tirtos7_ticlang ` project does not allow zigbee2mqtt to start. However, after consulting this document ( github.com/.../firmware.patch ) and modifying some configurations before recompiling the firmware, zigbee2mqtt was able to start successfully. Are there any other ways to address the maximum device limit for the Zigbee network when using the CC2674P10 as a coordinator? Currently, the limit is 100 devices, which is a bit low; I need to increase this to 200 or 400. I look forward to your reply.