Zigbee & Thread forum - Recent Threads

CC2340R5: Does the ZBoss protocol stack provide RF communication testing functionality? Or how can 802.15.4 RF communication testing be integrated into the ZBOSS project.

Aries Lord — Wed, 04 Nov 2026 03:22:15 GMT

Part Number: CC2340R5

Does the ZBoss protocol stack provide RF communication testing functionality? Or how can 802.15.4 RF communication testing be integrated into the ZBOSS project.

CC2340R5: How to run CCS project Base on simplelink_lowpower_f3_sdk_9_21_00_36_LTS in VS Code

Aries Lord — Mon, 02 Nov 2026 10:45:49 GMT

Part Number: CC2340R5

My project Base on simplelink_lowpower_f3_sdk_9_21_00_36_LTS is created in CCS v21, but I want run it in VS code. My VS code can run Codex.

CC26XX-REQUEST: Can RF signals interfere with the external low-frequency crystal oscillator of the CC2652P7?

zhimin he — Thu, 29 Oct 2026 06:59:05 GMT

Part Number: CC26XX-REQUEST
Other Parts Discussed in Thread: CC2652P7

My router incorporates a CC2652P7 Thread chip. When I use it in my office, which is within 200 meters of an air force base and a television station, the chip’s external low-frequency crystal oscillator behaves abnormally. As a result, the timer stops working, and the scheduled timeout never occurs.

However, when I take the device home, approximately 5 km away, the external low-frequency crystal oscillator resumes normal operation, and the timer works correctly again.

Could high-power RF signals in the surrounding environment cause this type of interference and prevent the external low-frequency crystal oscillator from operating properly?

CC2530: Schematics review

RAMJI VEDUYAPPAN — Wed, 28 Oct 2026 12:44:35 GMT

Part Number: CC2530

I need to review my schematics

CC2652P: ZigBee Router Occasionally Fails to Forward End Device Messages to the Coordinator

Roberto Nucera — Mon, 26 Oct 2026 07:56:53 GMT

Part Number: CC2652P
Other Parts Discussed in Thread: SYSCONFIG, Z-STACK

Hello,

We have been using these devices for several years in industrial installations where one or more ZigBee routers, each serving one or more end devices, are part of a ZigBee network.

Overall, the system works as expected. However, we have observed an issue in which, at certain times, a router stops forwarding messages from its end devices to the coordinator. We have verified this behavior using a ZigBee packet sniffer.

In our application, each router and end device periodically sends a message to the coordinator. The coordinator runs a Zigbee2MQTT application connected to a backend system. Upon receiving a message, the backend sends a response addressed to the originating device.

We implemented this application-level request-response mechanism to monitor end-to-end communication and verify that the connection is fully operational. If a device fails to receive a response for four consecutive requests, it triggers a software reset of the CC2652P processor. In most cases, communication is then successfully restored.

Packet sniffer analysis, also performed with the help of Codex AI, suggests that the issue may lie with the router: messages sent by its end devices appear not to be forwarded to the coordinator.

When the issue occurs, the router appears to behave in the same way for all end devices connected to it. In other words, the problem does not seem to be limited to a specific end device, but rather affects message forwarding from all end devices associated with the same router.

Interestingly, we have never experienced this issue in networks consisting only of end devices and the coordinator, with no routers involved. However, when routers are present, devices trigger software resets approximately twice a day.

Has anyone experienced similar behavior with ZigBee routers? Are there any known issues or configuration parameters that could cause a router to stop forwarding end device messages to the coordinator?

For reference, we are using the following software versions:

SDK: SimpleLink CC13xx/CC26xx SDK 8.30.1.01
SysConfig: 1.21.1

Any suggestions or insights would be greatly appreciated.

Thank you in advance for your help.

CC2652R7: CC2652R7: one chip draws ~20 µA extra in standby, follows the chip when swapped between boards

Rafal Wisniowski — Thu, 22 Oct 2026 08:45:36 GMT

Part Number: CC2652R7
Other Parts Discussed in Thread: Z-STACK,

One CC2652R7 on our battery-powered Zigbee end device (Z-Stack, SimpleLink SDK 8.30.01.01, TI-RTOS7) has a constant extra current of about 20 µA in standby. A second device running the same firmware behaves normally.

Measurements (3.0 V supply, 10 kS/s, 10-minute capture):

Device A (normal) - standby baseline - 0.2–0.4 µA, average when joined - 2.5uA

Device B (high) - standby baseline - 20-21 µA, average when joined - 23.6uA

- The offset is constant in every state: off-network, during pairing and joined. Device B never drops below about 16 µA.
- Active behaviour is the same on both: boot current, polls, and pairing timing and peaks.

What we've ruled out:
- The board: we swapped the MCUs between the two boards, and the high current followed the chip.
- The firmware: both chips were mass-erased and flashed with the same image. Read-back dumps show the application and CCFG are byte-identical; NV differs only in device identity and keys.
- Silicon revision and factory trims: FCFG1 shows the same ICEPICK ID (0x1BB7702F), FCFG1_REVISION (0x29), USER_ID and lot. VDDR, DCDC and LDO trims are identical. Only the normal per-die calibration values differ (e.g. MISC_TRIM recharge comparator offset 0x18 vs 0x0C, ANA2_TRIM NANOAMP_RES 0x2F vs 0x2A).

Device B die ID: 1e410040000000000022ab4fa8c00d68 (IEEE 00:12:4B:00:39:45:ED:F3)

Questions:
1. Is a constant ~20 µA standby offset on one die a known failure signature, e.g. ESD damage to an IO pad? Or could it be explained by its trim values?
2. What tests do you recommend to locate the leak (shutdown mode, specific pins or regulator settings)?

I can attach the current captures and FCFG1 dumps.

Thanks!

CC2530: Request for CC2530 Zigbee Module Schematic Review and Fee Quotation

RAMJI VEDUYAPPAN — Tue, 20 Oct 2026 10:15:56 GMT

Part Number: CC2530

We are designing an IoT Gateway that includes the CC2530 Zigbee module, which we are planning to interface via SPI. We would like to have our schematics reviewed to verify the interface connections and overall design.

Kindly review our schematics and share your feedback and recommendations.

vihaan1_iot_gateway_zigbee.pdf

CC2340R5: CC2340R5 and Low Power using ZBOSS and NoRTOS/RTOS

Flemming Christensen — Fri, 16 Oct 2026 11:52:54 GMT

Part Number: CC2340R5

I have a question about power consumption using CC2340R5 and Simplelink_lowpower_f3_sdk_9_23_00_27.

I will be using it for simple battery powered Zigbee devices and will need them to enter sleep mode.

In the examples the are two different types - NoRTOS and RTOS. My question is, will both types be able to reach low power modes? The reson I ask is becuse low power mode are mentioned only for RTOS in the documentation.

Br
Flemming

CC2340R5: CC2340R5(ZBOSS) can only send 16 broadcast in 9 second.

Aries Lord — Thu, 15 Oct 2026 06:59:24 GMT

Part Number: CC2340R5

How to make zigbee Broadcast Buffer larger in ZBOSS in SDK 9.21

CC2340R5: How to get the information in Coordinator's trust-join record table in ZBOSS of SDK 9.21

Aries Lord — Thu, 15 Oct 2026 03:17:34 GMT

Part Number: CC2340R5

I want access the trust-join record table ZBOSS of SDK 9.21, my MCU is CC2340R5.

CC2340R5: ZBOSS in simplelink_lowpower_f3_sdk_9_21_00_36_LTS can't support Fragment-Send.

Aries Lord — Thu, 08 Oct 2026 09:17:32 GMT

Part Number: CC2340R5

My CC2340 Tried to send a APS-data over 82 bytes, the data can't be sent in air

SENSOR-CONTROLLER-STUDIO: Can a small piezoelectric element detect chewing and rumination through a cattle collar?

Liu hongmao — Tue, 06 Oct 2026 06:56:02 GMT

Part Number: SENSOR-CONTROLLER-STUDIO

Complete probe: Ø16 mm × 1.5 mm
Piezoelectric ceramic element is integrated inside the probe.

CC2340R5: Some question of ZBOSS in simplelink_lowpower_f3_sdk_9_21_00_36_LTS

Aries Lord — Wed, 30 Sep 2026 08:26:52 GMT

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

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.

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.

CC2755R10: COEX_REQ error

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

Part Number: CC2755R10
Other Parts Discussed in Thread: CC3301,

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?

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?

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.

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.

CC2652P7: In what mode does the Thread chip cause timer exceptions while GPIO hardware interrupts can still trigger normally?

zhimin he — Tue, 01 Sep 2026 08:52:46 GMT

Part Number: CC2652P7

We have developed an alarm clock feature using the CC2652P7 Thread chip. When the main chip is completely powered off, the Thread chip can power on the main chip through either a timer or a GPIO interrupt triggered by an external button.

We have discovered that after the main chip is powered off, the Thread chip enters a state where the timer is malfunctioning, but GPIO hardware interrupts triggered by external buttons can still trigger normally. This situation does not occur deterministically, but has a high probability of happening in specific environments.

We suspect that the Thread chip has entered a low-power mode. However, according to TI’s documentation, neither the standbyPolicy nor the doWFI low-power modes should cause the timer to stop working.

Therefore, we would like to know in what mode the Thread chip could cause timer exceptions while GPIO hardware interrupts can still trigger normally?

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
Other Parts Discussed in Thread: CC2340R5, SYSCONFIG

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,

CC2652P7: API to get Z-Stack version

Shuyang Zhong — Fri, 24 Jul 2026 12:32:09 GMT

Part Number: CC2652P7
Other Parts Discussed in Thread: Z-STACK

My customer is running ZNP for a Zigbee gateway. They would like to get the Z-Stack version from sys_version from Z-Stack monitor and test API, but the returned version does not match the version number in the release note.

From the returned value it seems the sys_version API is retuning the version from \source\ti\zstack\stack\api\zsversion.h, but the Z-stack version in release note is the same as the core SDK version. What does the version numbers in zsversion.h represent?

Is there an API to get the version matching the release note version? It's better to be a monitor and test API since ZNP is running on the device.

Best regards,

Shuyang

CC2652P: Supporting co-existence of Zigbee 3.0 (ZCL) devices and Proprietary Zigbee PRO nodes (Modbus) via ZNP interface on CC2652P

anqi su — Mon, 13 Jul 2026 07:24:35 GMT

Part Number: CC2652P
Other Parts Discussed in Thread: Z-STACK

I am developing a Zigbee gateway solution utilizing the CC2652P as a coordinator. A key requirement is to support both standard Zigbee 3.0 (ZCL-based) devices and proprietary Zigbee PRO-based sensors that utilize custom protocols (e.g. Modbus RTU).

I have the following questions regarding the ZNP (Zigbee Network Processor) interface:
1.Is it possible to implement a multi-protocol gateway architecture by dynamically adjusting API frame parameters—specifically the Endpoint, Profile ID, and Cluster ID—at the host MCU level to differentiate between standard ZCL communication and proprietary data tunneling?
2.I am concerned that switching between these different message types might affect network management commands (such as networking, join/rejoin, and routing).

Any architectural guidance or best practices you can provide for this heterogeneous traffic handling would be greatly appreciated.

CC2652P7: Critical Z-Stack Firmware Bug

Dirk Freiherr zu Wilmannsberg — Fri, 26 Jun 2026 11:16:39 GMT

Other Parts Discussed in Thread: CC2652P7, Z-STACK, CC2652R

CRITICAL Z-STACK FIRMWARE BUG: CC2652P7 SRSP AF Data Buffer Overflow / Lockup during high-volume Cluster Requests (e.g., GenTime)

I am managing a large-scale deployment controlling safety-critical infrastructure, including automated commercial gates and traffic light systems. Under high load, the CC2652P7 regularly locks up completely due to an unhandled Synchronous Response (SRSP) / Asynchronous Framework (AF) data buffer overflow.

The issue triggers when end-devices flood the coordinator with specific cluster requests—specifically GenTime queries (Cluster 0x000A). Instead of gracefully discarding unhandled requests, dropping timed-out packets, or returning a clean error code to the host application (Zigbee2MQTT/zigbee-herdsman), the Z-Stack's internal memory management for 'AF - dataRequest' completely saturates. Once the SRSP buffer is full, the entire serial interface freezes, requiring a hard power cycle and a complete NVRAM flash to restore functionality every few hours.

As an enterprise-grade component provider, TI cannot expect customers running critical infrastructure to implement absurd workarounds like physically cutting power to the MCU via external relays just because the Z-Stack fails to clear its own asynchronous command buffers. A simple web search proves that the community is plagued by these "SRSP AF" and Z-Stack crash loops on the CC2652 series.

I need immediate technical clarification from your engineering team on the following points:
1. Why does the Z-Stack fail to implement a strict FIFO/LIFO timeout mechanism to clear stalled AF requests from the memory before a total lockup occurs?
2. Is there an undocumented configuration parameter or a specific patch in the SimpleLink SDK that prevents the SRSP interface from freezing when flooded with unhandled cluster requests?
3. What is TI’s official roadmap to fix this severe stability flaw in the Z-Stack core firmware?

Please forward this directly to a Senior Z-Stack Systems Engineer. This is a production-stopping issue for a safety-critical environment.

CC2652P: RED certification tests

Roberto Nucera — Fri, 19 Jun 2026 06:59:56 GMT

Other Parts Discussed in Thread: CC2652P

CC2652P device:

we are currently preparing the RED certification process for our electronic device, which integrates your radio module on board.

For the certification tests, the laboratory is requesting a dedicated firmware version for continuous transmission mode, with the following requirements:

radio band occupation greater than 98%;
operation on the highest radio channel;
transmission at maximum output power;
availability for both BLE and ZigBee modes.

Could you please confirm whether you already have these firmware versions available and, if so, whether you can provide them to us so that we can load them directly onto the radio module?

Please also let us know if there are any specific instructions, tools, or procedures required for programming the module with these firmware versions and for setting the maximum transmission power.

We remain available for any additional technical information you may need.

BR Luigi