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.

RE: 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.

Alex Fager — Wed, 04 Nov 2026 17:22:00 GMT

Hello Aries Lord,

Can you expand on what you would like to test?

We do have the SmartRF Studio 8 tool today which does have the IEEE PHY which you can test with:

If you need something more specific (packet control wise) then I would recommend you modify the rfPacketRx/rfPacketTx example to use the IEEE PHY.

Thanks,
Alex F

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.

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

Lea — Tue, 03 Nov 2026 11:37:26 GMT

Hi !

You can run your CCS-based project in VSCode by using the cortex-debug extension. We have a TI wrapper around this extension called "TI embedded debug for VSCode". You can find how to setup and use this extension in this SLA : https://dev.ti.com/tirex/explore/node?isTheia=false&node=A__AflMXhjgOJzcT3t6UNLyfg__SIMPLELINK-ACADEMY-CC23XX__gsUPh5j__LATEST

This SLA was made with Zephyr in mind, but it will also work with a SimpleLink .out file.

Kind regards,
Lea

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

Faizan Habib — Mon, 02 Nov 2026 12:35:33 GMT

Hi Aries,

Thank you for reaching out.

An expert on the topic will get back to you.

Best Regards.

Faizan

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

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?

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

Katherine Ogrean — Fri, 30 Oct 2026 20:19:59 GMT

Hi,

Typically, ambient external RF fields do not disturb the CC2652P7's external 32.768-kHz crystal oscillator. There is one documented RF-related mechanism that stops this oscillator, and it involves the device's PA, not an external transmitter.

What is documented

The CC2652P7 errata describe a single oscillator-stoppage condition: at temperatures below −20 °C, high-power PA operation can affect the 32-kHz crystal oscillator through RF load-impedance mismatch; the oscillator may stop and reset the device when the clock-loss detector is enabled 1.

Specified mitigations for that condition:
- Follow the reference RF balun and matching-network component values and layout, with balun amplitude and phase balance better than 1 dB and 6 degrees 1
- Avoid antenna impedances outside VSWR 2:1 in all operating scenarios 1
- Limit RF output power to 17 dBm maximum for non-reference PCB designs or where antenna impedance can vary 1
- Enable clock-loss detection (OSC_DIG:CTL0.CLK_LOSS_EN = 1) so the device resets if the oscillator stops 1

Note the relevance to your case: your office is at room temperature, so the errata condition itself does not apply. However, the mechanism is load-impedance mismatch at the antenna coupling into the oscillator. A strong external field incident on your antenna changes the RF environment the PA sees, which is the same physical domain — but this extrapolation is not documented by TI.

Knowledge gap — flagged explicitly

The retrieved material contains no RF-immunity specification, susceptibility threshold, injection-pulling data, or oscillator-specific RF-coupling limit for the CC2652P7 LF crystal. The product parametric lists only 32.8 kHz LF clock frequency, 350 ppm frequency-error tolerance, 50 ppm/°C temperature coefficient, and 600 ppm calibrated RTC variation — nothing on interference susceptibility 2. E2E threads involving CC2652P7 RF problems attributed failures to matching-network values, PCB layout, or incorrect PA components, never to LF-oscillator coupling 3.

So your location-correlated symptom cannot be confirmed or ruled out from existing documentation. It requires isolation testing on your board.

Isolation steps

Confirm the oscillator is actually the failing element. Poll XOSCLFRIS, which indicates XOSC_LF has been frequency-qualified and stays asserted until the oscillator is disabled 4. Log it at the office. If it never deasserts, your timer fault lies elsewhere in the software/protocol stack, not in the crystal.
Switch the LF source to the internal RC oscillator. The low-frequency clock can use the internal 32-kHz RC oscillator, an external clock on a DIO, or the crystal 5. If the timer fault persists on RCOSC_LF, the crystal is exonerated.
Verify the crystal meets spec — 32.768 kHz across X32K_Q1 (pin 8) and X32K_Q2 (pin 9), ESR 30 kΩ typical / 100 kΩ maximum, load capacitance 6–12 pF with 7 pF typical on TI reference designs 6 7. A high-ESR crystal or load-cap mismatch leaves minimal startup margin, which makes marginal designs fail under any added stress.
Review RF layout against the reference design. The datasheet directs designers to the CC13xx/CC26xx Hardware Configuration and PCB Design Considerations application report, emphasizing close adherence to reference component placement, decoupling, DC/DC layout, and ground connections 8. Verify your antenna VSWR in the deployed enclosure.
Reproduce deliberately. The only way to confirm external-field causality is a conducted or radiated immunity test with the symptom correlated against XOSCLFRIS.

Best,

Katy

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

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!

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

Katherine Ogrean — Thu, 29 Oct 2026 19:31:19 GMT

Hi Rafal,

I'm glad your issue has been resolved and thank you for the update!

Generally, when a pin is floating and it is not assigned a state then there is no way to determine what state it will be in. This will lead to varried results like you have seen here.

Best,

Katy

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

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.

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

Alex Fager — Thu, 29 Oct 2026 15:59:03 GMT

Hello Luigi (Roberto)

I will pend on your further feedback here when the time comes!

Thanks,
Alex F

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

Rafal Wisniowski — Thu, 29 Oct 2026 11:37:48 GMT

I did test more devices recently, and the problem was occurring on roughly 30-40% of them. But fortunately I`ve been able to locate the issue. We have external memory connected through SPI - and the main problem was the MISO/POCI pin.

So generally our fix was a one-liner - adding internal pulldown to MISO/POCI pin.

After this change we can measure very similar current on every device on 3V supply voltage. Still not sure why it doesn't work the same on every MCU. Any insight on that ?

Regards,

Rafal

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

Roberto Nucera — Thu, 29 Oct 2026 08:59:38 GMT

Hi Alex! Thanks a lot for your answer.....

We'll try our best to follow your suggestions.

B.R.

Luigi (Roberto)

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

RAMJI VEDUYAPPAN — Thu, 29 Oct 2026 07:19:33 GMT

e2e.ti.com/.../VIHAAN1_5F00_IOT_5F00_GATEWAY_5F00_20261020_5F00_12.pdf

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(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

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

Ging Gonzalez — Wed, 28 Oct 2026 20:47:23 GMT

Hi Aries,

We can build a library for you with your desired BTR Table Size. However, to do this, please reach out to your local FAE and make a formal request. Thank you!

Regards,
Ging

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

FI — Wed, 28 Oct 2026 15:30:46 GMT

Sorry for the dela here. Please submit this design here and we will review this quickly.
www.ti.com/.../SIMPLELINK-2-4GHZ-DESIGN-REVIEWS

RE: CC2530: Schematics review

Katherine Ogrean — Wed, 28 Oct 2026 14:56:26 GMT

Hi,

We don't do design reviews on this platform. Please fill the form and submit all design files to the URL below:
https://www.ti.com/tool/SIMPLELINK-2-4GHZ-DESIGN-REVIEWS

You can also go to the product page: CC2530EMK Daughter card | TI.com and download the design files to use as a reference in your design.

Best,

Katy

CC2530: Schematics review

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

Part Number: CC2530

I need to review my schematics

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

RAMJI VEDUYAPPAN — Wed, 28 Oct 2026 12:46:24 GMT

Kindly Review and give your feed back

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

Katherine Ogrean — Tue, 27 Oct 2026 20:25:25 GMT

Hi Rafal,

Are you testing the device on your custom board or a TI launch pad? If it is on a custom board then I would recommend putting the device on a launch pad to check if this is a hardware PCB issue.

I also suggest that you try putting the device in standby mode while running a BLE example from our SDK. If there is not high current draw while it is running BLE then there is probably a software issue related to Zigbee. I suggest modifying the simple_peripheral example from the SDK to not blink the LED and it will then send the device into standby mode.

Let us know if it is determined to be an issue with the CC2652R7 device.

Best,

Katy

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

Alex Fager — Tue, 27 Oct 2026 18:46:47 GMT

Hello Aries Lord,

Sorry for the delay here, I still have not gotten feedback from RnD so I reached back out and have escalated the question.

Thanks,
Alex F

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

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

Alex Fager — Tue, 27 Oct 2026 15:11:26 GMT

Hello,

In terms of troubleshooting, the Z-Stack documentation provides a few key areas to investigate regarding how these devices handle message flow:

APS Acknowledgements: If the router does not receive an APS acknowledgement from the next hop, it will attempt retries based on the APSC_MAX_FRAME_RETRIES setting (default is 2) before reporting a failure 1. Confirming whether your sniffer shows the router attempting these retries can tell us if the radio is successfully sending the frame or if the stack has stopped processing the queue entirely.
Routing Parameters: In larger or more complex mesh networks, ensuring that your LINK_DOWN_TRIGGER and NWK_ROUTE_AGE_LIMIT are tuned for your specific environment is critical 1. If the router marks a route as faulty prematurely, it may stop forwarding until a new route discovery is triggered.
Security Policies: We have seen cases in some network topologies where specific frames (like "Update Device" commands) are rejected by a coordinator if the APS security policy is too restrictive. If your application or network environment involves frequent re-joins, ensuring zgApsAllowR19Sec is set correctly in zglobals.c can sometimes prevent silent drops 2.

If you are able to capture the state of the neighbor table or confirm the retry behavior via your sniffer during one of these two-a-day events, that would provide the best path forward for a more specific diagnosis.

Thanks,
Alex F