Zigbee & Thread forum - Recent Threads

CC2340R5: CC2340R5: Both zb_zdo_simple_desc_req and zb_zdo_active_ep_req have reported timeouts, but the retransmission is still continuing.

Aries Lord — Fri, 18 Sep 2026 13:59:57 GMT

Part 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.

RE: CC2340R5: CC2340R5: Both zb_zdo_simple_desc_req and zb_zdo_active_ep_req have reported timeouts, but the retransmission is still continuing.

Aries Lord — Fri, 18 Sep 2026 14:01:11 GMT

SDK is simplelink_lowpower_f3_sdk_9_21_00_36_LTS and simplelink_lowpower_f3_sdk_9_20_00_81

RE: CC2652R: RX fails using TI Simplelink SDK 8.30.01.01

Daniel Guarecuco Aguiar — Fri, 18 Sep 2026 12:51:14 GMT

Hi Martin,

I'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,

Daniel

CC2652R: RX fails using TI Simplelink SDK 8.30.01.01

Martin Meier — Wed, 16 Sep 2026 11:53:11 GMT

Part 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'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't find anyting in the 8.31.00.11 changelog that matches this behaviour.

RE: CC2652R: RX fails using TI Simplelink SDK 8.30.01.01

Martin Meier — Thu, 17 Sep 2026 13:00:53 GMT

Hi Daniel,

Ok, do you suggest that such memory corruption would recover by triggering a CCA energy detect scan?

RE: CC2652R: RX fails using TI Simplelink SDK 8.30.01.01

Daniel Guarecuco Aguiar — Thu, 17 Sep 2026 12:48:18 GMT

Hi 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 & Thread forum - Zigbee & Thread - TI E2E support forums

I think might be a related issue.

Best regards,

Daniel

RE: CC2652R: RX fails using TI Simplelink SDK 8.30.01.01

Martin Meier — Thu, 17 Sep 2026 11:36:41 GMT

Hi 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.

RE: CC2652R: RX fails using TI Simplelink SDK 8.30.01.01

Daniel Guarecuco Aguiar — Thu, 17 Sep 2026 10:46:41 GMT

Hi 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,

Daniel

RE: CC2674P10: CC2674P10: ZDSECMGR_TC_DEVICE_MAX upper limit

jun cao — Tue, 15 Sep 2026 02:14:59 GMT

Alex Fager :

Thank you for your reply.

I added '#define NVOCMP_NVPAGES 10', 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?

CC2674P10: CC2674P10: ZDSECMGR_TC_DEVICE_MAX upper limit

jun cao — Tue, 08 Sep 2026 12:20:52 GMT

Part Number: CC2674P10

Hi team:

env:
1. SDK: SimpleLink™ CC13xx CC26xx SDK 8.30.01.01

2. project: znp_LP_EM_CC2674P10_tirtos7_ticlang

3. chip: CC2674P10

I read a post on E2E (https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1385908/lp-em-cc1354p10-zdsecmgr_tc_device_max-upper-limit?tisearch=e2e-sitesearch&keymatch=NVOCMP_NVPAGES#), and after setting:

1. ZDSECMGR_TC_DEVICE_MAX to 200

2. NVOCMP to 0xA, HEAPMGR_SIZE to 4096, and recompiling the ZNP project, I flashed the firmware to a CC2674P10, using the CC2674P10 as the coordinator, but zigbee2mqtt still failed to boot.

I don't know why zigbee2mqtt failed to boot. However, when I set ZDSECMGR_TC_DEVICE_MAX to 100, zigbee2mqtt started successfully again.

Could a TI technician help me analyze this?

RE: CC2674P10: CC2674P10: ZDSECMGR_TC_DEVICE_MAX upper limit

Alex Fager — Mon, 14 Sep 2026 21:03:34 GMT

Hello 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 F

RE: CC2674P10: CC2674P10: ZDSECMGR_TC_DEVICE_MAX upper limit

jun cao — Mon, 14 Sep 2026 03:07:48 GMT

Hi 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.

RE: CC2674P10: CC2674P10: ZDSECMGR_TC_DEVICE_MAX upper limit

Alex Fager — Fri, 11 Sep 2026 20:02:45 GMT

Hello jun cao,

Thanks for confirming with the pictures, on my end after compiling a ZNP example and flashing it to a CC2674P10 device the following is what I see in the PuTTY window:

I also tested the z-tool to see if it can find and control the device and it unfortunately did not.

From what I can conclude here the ZNP project for the CC2674P10 does not currently work, at least when attempting to open the project with z-tool (what was recommended in the readme). Though it's interesting that zigbee2mqtt can seem to work with it from what you report.

We currently do not recommend developers to develop on (or go to production) with the F2 devices (such as the CC2674P10) and instead recommend the F3 (CC23, CC27) devices.

Thanks,
Alex F

RE: CC2652PSIP: Having antenna range issues with custom cc2652psip board

Katherine Ogrean — Fri, 11 Sep 2026 16:40:47 GMT

Hi,

From the information you have provided I think the issue might be a manufacturing / assembly issue. This could be due to the antenna or the assembly of the RF path. I suggest looking at the 2.4-GHz Inverted F Antenna (Rev. D) application note to ensure the implementation of the inverted F antenna is correct. Additionally, make sure all layout recommendations are followed in section 10 of CC2652PSIP SimpleLink™ Multiprotocol 2.4-GHz Wireless System-in-Package With Integrated Power Amplifier datasheet (Rev. B). I would also recommend testing the custom board Tx to see if you are seeing the same performance degradation as in Rx.

Best,

Katy

CC2652PSIP: Having antenna range issues with custom cc2652psip board

Pavan kumar yalamanchili — Mon, 07 Sep 2026 12:09:18 GMT

Part Number: CC2652PSIP

i have inverted f antenna on pcb , with launchpad ble i can achieve like 7 rssi when it's close to mobile phone , on my custom board it's was like 22 rssi , long range also has issue, i just want to know how to resolve this issue in hardware level.tested with smart rf studio has rougly max 10 rssi difference between launcpad and custom board. zigbee protocol and ble protocol example are giving big difference like 15.

additional info
4 layer fr4 pcb

in between sip and antenna it has 15pf capacitor in series.

CC2755R10: COEX_REQ error

Ohata Reiji — Wed, 09 Sep 2026 08:34:57 GMT

Part Number: CC2755R10

Hi,

Our developing device uses CC2755R10 with CC3301 to use Zigbee and BLE/WiFi. Therefore I edited syscfg like below.

However, COEX_REQ and COEX_PRIORITY are not work. When it receives some packets, these 2 line are still Low. To solve this problem, I edited rcl_stub_dmm.c like below.

DMM_WEAK_FUNC RCL_CommandStatus OVRDE_RCL_Command_submit(RCL_Handle h, RCL_Command_Handle c)

{

((RCL_CmdIeeeRxTx*)c)->coexControl.grantEnable = 1;

((RCL_CmdIeeeRxTx*)c)->coexControl.requestPriorityEnable = 1;

return RCL_Command_submit(h, c);

}

By this change, COEX_REQ is become HIGH and COEX_PRIORITY is still Low when it receives some packets.

[Question]

1. Is this change correct? If no, could you tell me how to fix it?

2. Does COEX_PRIORITY not become High, when receive?

RE: CC2755R10: COEX_REQ error

Ohata Reiji — Fri, 11 Sep 2026 08:11:51 GMT

Hi Alex,

Thank you supporting.

RE: CC2755P10: CC2755P10: Availability/roadmap of ZBOSS NCP (SNCP) device-side build for CC23xx/CC27xx

Levent Sagiroglu — Fri, 11 Sep 2026 06:15:45 GMT

Hi Ging, hi Jan,

Thank you both — understood on NCP not being supported today, and I appreciate you
taking this to R&D. We will wait for your update next week.

One note in case it helps them scope the answer: of the questions in my original
post, the one that actually unblocks our design is item 5 — whether a
customer-implemented serial coprocessor on top of the supported SoC-mode ZC role is
a viable and supportable approach on CC2755P10.

Thanks,
Levent

CC2755P10: CC2755P10: Availability/roadmap of ZBOSS NCP (SNCP) device-side build for CC23xx/CC27xx

Levent Sagiroglu — Fri, 28 Aug 2026 07:49:34 GMT

Part Number: CC2755P10

SDK version: simplelink_lowpower_f3_sdk_9_21_00_36_LTS (Zigbee 1.00.00, ZBOSS 4.x, R23 + R22)

Hi,

We are evaluating a host-plus-coprocessor gateway architecture:

Host (Linux PC / embedded Linux) ---UART or SPI--- CC2755P10
ZBOSS NCP Host / gateway app NCP firmware (ZBOSS, R23)

Before committing to a design, I would like to confirm what TI supports today.

What I found in the SDK:

1. The Zigbee stack is ZBOSS, and NCP hooks are already present in TI's porting layer:
- source/ti/zigbee/include/zb_config_platform.h: NCP_MODE is handled, and
ZB_OSIF_NCP_TRANSPORT_PREPARE_TO_SLEEP() maps to zb_osif_spi_prepare_to_sleep()
- source/ti/zigbee/osif/ti_f3/ti_f3_main.c and ti_f3_serial.c contain several
#ifdef NCP_MODE / #ifndef NCP_MODE blocks
- source/ti/zigbee/osif/include/zb_hal_utils.h defines an NCP flash layout via
linker symbols: ZBS_NCP_IMAGE_ADDR, ZBS_NCP_NVRAM_BASE, ZBS_NCP_RESERV_BASE,
ZBS_NCP_PROD_CFG_BASE, ZBS_NCP_CCFG_PAGE_BASE
- The same header has: #if defined SNCP_MODE ... #error "SNCP mode needs to be implemented"

2. NCP API headers ship with the stack:
source/third_party/zigbee/zboss_r23/include/ncp/{ncp_common_api.h, ncp_dev_api.h,
ncp_host_api.h, zb_ncp_ll_dev.h} and include/zb_ncp.h
(these appear to cover only the zb_ncp_custom_* extension API)

3. However, the pieces needed to actually build an NCP device are not in the SDK:
- source/third_party/zigbee/libraries/zboss_r23/ contains SoC-mode libraries only
(zb_r23_core_zc_zr, zb_r23_zdo_*, zb_r23_zcl_*, zb_r23_ti_platform_*, zb_mac);
there is no NCP device library
- No NCP example under examples/rtos/LP_EM_CC2755P10/zigbee/ (or for CC2340R5)
- The SysConfig Zigbee module (source/ti/zigbee/.meta/zigbee.syscfg.js) offers only
zc / zr / zed / mac / gpd device types, with no NCP option
- No SPI osif implementation (zb_osif_spi_*) is provided in source

Questions:

1. Is an NCP (or SNCP) device-side build for CC23xx / CC27xx planned? If so, is there a
target SDK release?
2. Is an NCP device library or firmware image available today under NDA or through a
commercial ZBOSS license from DSR Corporation for TI parts? What is the correct
channel to request it (TI or DSR directly)?
3. If we license it, which serial transports are supported on CC27xx (UART, SPI, both),
and would the resulting device be compatible with DSR's ZBOSS NCP Host?
Which ZBOSS NCP serial protocol version does the TI stack implement?
4. Is there an ABI/version constraint we should know about, e.g. would the NCP device
library be built against the same ZBOSS core version as the SoC-mode libraries in
9.21.00.36 LTS?
5. If NCP is not an option in the near term, is a customer-implemented serial
coprocessor on top of the SoC-mode ZC role a supported approach? Is the
dmm/ble_hci_ser_mux example an acceptable reference for the UART transport layer?

For context, our target is a Zigbee 3.0 R23 gateway with CC2755P10 as the coordinator
(integrated PA is a key reason for the choice), with a Linux host running the
application/gateway logic. The alternative we are evaluating is a competing NCP-capable
SoC, so knowing TI's position here would help us keep the design on CC27xx.

Thanks,

RE: CC2674P10: CC2674P10: ZDSECMGR_TC_DEVICE_MAX upper limit

jun cao — Fri, 11 Sep 2026 02:51:09 GMT

Hi Alex Fager :

I have configured the settings based on the screenshot you provided, as shown below:

However, zigbee2mqtt is reporting the same error as before, as shown below:

[quote userid="567427" url="~/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1680390/cc2674p10-cc2674p10-zdsecmgr_tc_device_max-upper-limit/6479918"]As a separate question do you plan to go to production with the CC2674P10 with zstack? [/quote]

Yes, but during our testing, we found that when the CC2674P10 is used as the coordinator, only 40 devices can be added to the Zigbee network. This number is too low, so we submitted the issue to E2E to see if a solution could be provided.

CC2674P10: CC2674P10 Openthread RCP: Wait for response timeout

jun cao — Fri, 04 Sep 2026 10:25:44 GMT

Part Number: CC2674P10

Hi Team:

env:
1. https://github.com/TexasInstruments/ot-ti (tag: thread-ti-v1.3-1.0)

2. Dongle(CC2674P10)

1. Flash the OpenThread RCP firmware to the Dongle and then insert it into HAOS.

2. In HAOS, after the OTBR APP starts, the error "Wait for response timeout" occurs.

I don't know why this error occurs. However, I can provide my log file.

I can provide more details if needed. Thank you.

RE: CC2674P10: CC2674P10 Openthread RCP: Wait for response timeout

jun cao — Fri, 11 Sep 2026 01:55:35 GMT

Hi Alex Fager :

1. Where should the code be added—in the OTBR app or in OT-TI?
2. What kind of code should be added?

I look forward to your reply.

RE: CC2674P10: CC2674P10 Openthread RCP: Wait for response timeout

Alex Fager — Thu, 10 Sep 2026 21:25:21 GMT

Hello jun cao,

[quote userid="716594" url="~/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1679526/cc2674p10-cc2674p10-openthread-rcp-wait-for-response-timeout/6478929"]is it a known bug or something else?[/quote]

I do not see any bug referencing this issue in the github.

We may need to add some direct logging code to the actual software to export the current RCP table.

Thanks,
Alex F

RE: CC2755P10: CC2755P10: Availability/roadmap of ZBOSS NCP (SNCP) device-side build for CC23xx/CC27xx

Ging Gonzalez — Thu, 10 Sep 2026 20:57:57 GMT

Hi Levent,

Thank you for looking into this and reaching out! We currently do not support NCP and I cannot commit to a timeline or target SDK release, but let me reach out to our R&D teams and get more details for your questions. Give me until next week to get back to you. Thanks!

Regards,

Ging

RE: CC2755R10: COEX_REQ error

Alex Fager — Thu, 10 Sep 2026 18:56:35 GMT

Hello Ohata Reiji,

Going off of the diagram below the signals for Priority and Grant seem to be working correctly, and the Zigbee device should be allowed to perform the TX/RX operations so the code setup seems ok.

I am not aware of how exactly the setup on the CC33 side would work, as you want the CC33 to also do BLE I am not sure how its own Priority/Grants would work.

Thanks,
Alex F