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/1658992/cc2652p7-critical-z-stack-firmware-bug/6406460Mon, 06 Jul 2026 22:32:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:566572be-1ad4-402d-b6e4-22d6f703f577Daniel OlisHi Dirk, Rest assured that we are taking this very seriously and trying to offer a solution that will satisfy both parties. July 3 rd was a holiday as substitute for the July 4 th national holiday in the USA hence our delay in response. Regarding this point and our inability to open the log you provided on TI’s network, please understand that in no way are we trying to stall. We understand that our customers create products that have real-world impact so we take our technical support seriously. If any of the responses made on this forum/thread feel like we are undermining your expertise, please understand that we generally need to make sure we have all the details and that every debugging option has been tried to identify the proper solution. Regarding making Z-Stack open source and any legal and liability matters regarding TI, I have emailed you directly along with our experts on the matter to continue discussion offline where we&#39;d like to clarify some of the details, what would be acceptable from your side, etc. Regards, Daniel Important notice and disclaimer | Texas Instrumentshttps://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1658992/cc2652p7-critical-z-stack-firmware-bug/6404673Fri, 03 Jul 2026 17:01:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:18c8d368-fe57-4f2e-bae7-a657c108217bDirk Freiherr zu WilmannsbergAnother day is over whitout any result or at least reaction from TI. My patience has officially run out. I have been dealing with this absolute joke of a firmware lockup for over 4 weeks now. Initially, your support response felt like you assumed I’m some hobbyist sitting at home with 5 smart bulbs. Let me repeat: I am operating a commercial/industrial site. We are running a heavy-duty network with 120 Zigbee devices, including 111 Routers, flooding high-volume cluster data (real-time power reporting, industrial light signals, etc.). We bought the most expensive, premium LAN gateway on the market (SMLIGHT SLZB-06P7), specifically relying on your advertised hardware specs for the CC2652P7. To be honest, I am genuinely surprised and furious that SMLIGHT even integrates such garbage components into their hardware despite this being a known issue. If I had known beforehand what kind of faulty, broken junk TI delivers here, I would have absolutely chosen a product with a Silicon Labs chipset instead. Right now, your broken, closed-source Z-Stack is paralyzing our facility because the SRSP/AF data buffers overflow and crash the coordinator without hardware flow control no matter at 115200 or at 460800 baud. During the course of this thread, I have contacted several distributors and industry insiders. To my absolute horror, I was informed that this specific buffer overflow bug is a well-known, long-standing issue that TI has simply chosen to ignore for months, if not years. It is completely unacceptable that you consciously keep selling and promoting a certified industrial Zigbee 3.0 platform with a known, game-breaking architectural defect. Before moving to local control, this exact network ran for 6 months completely flawlessly in the Tuya Cloud. Now, because of TI&#39;s faulty Z-Stack, we have an expensive piece of digital bricks. I am not someone who will let you waste my time or ride this out. Here is my ultimatum: I expect a concrete, binding statement and a definitive technical decision from TI by Monday at the latest. If there is no solution or clear roadmap by Monday, I will immediately take the following actions: 1. File an official complaint with the FTC (Federal Trade Commission) in the US for misleading advertising and selling a fundamentally broken product under real-world load. 2. Initiate regulatory proceedings with European consumer protection and trade authorities to enforce a sales ban/product recall based on non-compliance with digital product warranties (Sachmangel), since your hardware fails to deliver the promised scale. 3. Launch the most massive, relentless public campaign/shitstorm across all major social media platforms and developer forums. I will publicly expose TI&#39;s incompetence, their systemic ignorance toward their own distributors, and how they treat business-critical infrastructure clients. The smart home and industrial community needs to know exactly what kind of unreliability they are buying into. 4. If your internal team is too incompetent to patch this buffer overflow, OPEN-SOURCE the Z-Stack binary components (like libZStack_nwk_all.a) immediately so the community can fix your mess for you. Silicon Labs manages to keep their stacks transparent and stable. If TI continues to ignore critical enterprise-ruining bugs, we—and the entire community—will permanently migrate to Silicon Labs hardware. The clock is ticking. I expect an answer by Monday. In this sense, I wish your team a great weekend. Dirk Freiherr zu Wilmannsberghttps://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1658992/cc2652p7-critical-z-stack-firmware-bug/6403214Thu, 02 Jul 2026 15:47:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:0a3900b5-156f-4262-b6bf-52520b4cadaaDirk Freiherr zu WilmannsbergSubject: RE: CC2652P7: Critical Z-Stack Firmware Bug - URGENT: Safety Risk &amp; Liability Notice Hello Ryan, To answer directly: Yes, it is imperative to escalate this matter immediately to your CEO, senior management, and your Legal &amp; Compliance Department. This is no longer a standard firmware issue; this is a critical safety hazard with massive liability exposure for Texas Instruments. I have consulted various sources across the internet, including SM Light, the Zigbee community, and other manufacturers who utilize this chip, and I received the exact same feedback everywhere: this problem has been known to TI for quite a long time, yet absolutely nothing fundamental has been done to resolve it. We personally consider this complete lack of action to be entirely irresponsible. The Real-World Impact: Our system controls two traffic lights managing a single-lane bridge with blind spots, secured by these signals. We migrated away from other solutions specifically for local reliability. However, with this current Z-Stack bug, the TI chip freezes unpredictably. If this occurs at the wrong moment—leaving a signal stuck on &quot;Green&quot; while opposing traffic enters the bridge—it will result in severe property damage and, potentially, loss of human life. Legal &amp; Financial Risks: Under product liability law, the financial consequences for manufacturing or distributing a known, defective component that causes bodily harm are catastrophic. Now that this issue has been documented and communicated through official TI channels, any failure to act introduces the element of willful negligence. In the United States, if responsible parties are aware of a critical safety defect and fail to take immediate action, this can lead to severe punitive damages and criminal liability for corporate officers. The Solution: Open Source the Z-Stack Immediately We understand that TI may currently lack the internal resources to reproduce, fix, and thoroughly test this bug under tight deadlines. Therefore, the most responsible decision Texas Instruments can make is to immediately release the Z-Stack source code as Open Source. The Zigbee community has the expertise to isolate and fix this issue rapidly. Open-sourcing the stack would: 1. Mitigate TI’s legal exposure by allowing the community to deploy a fix. 2. Protect human lives and critical infrastructure. 3. Protect the company&#39;s reputation by demonstrating transparency. Please escalate this to your legal counsel and executive team without delay. We require a formal response regarding how TI plans to mitigate this safety risk immediately. Best regards, Dirk Freiherr zu Wilmannsberghttps://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1658992/cc2652p7-critical-z-stack-firmware-bug/6401413Wed, 01 Jul 2026 14:11:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:4a222bae-df15-48e6-bae1-4475dafe8385Ryan Brown1Hi Dirk, Thank you for your advice and feedback. I&#39;ve alerted my leadership so that they are aware of your requests. Regards, Ryanhttps://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1658992/cc2652p7-critical-z-stack-firmware-bug/6399951Tue, 30 Jun 2026 15:20:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:a321ca33-9011-48a1-b7ea-659c138eee71Dirk Freiherr zu WilmannsbergHi Ryan, postimages.org is a standard, globally accessible image host. If TI&#39;s internal corporate firewall restricts access to it, use a mobile device or a non-corporate network to review the data. The logs and maps are vital for understanding this issue, and I will not do basic network troubleshooting for your internal IT. Let&#39;s address your technical points and the reality of this situation: 1. Baud Rate &amp; High-Speed Failure Realities You asked if we are using 921600 baud. We have raised the UART baud rate from 115200 to 460800 baud to open up the serial bottleneck. This change has temporarily elongated the time between hard lockups—running for about 4 to 5 hours now instead of crashing every 1 to 2 hours. However, let me be absolutely clear: increasing the baud rate only cushions the blow; it does not heal the disease. I fully expect the system to crash again within hours. While the coordinator is not dying immediately, the internal Z-Stack tables are still exhausting themselves, throwing continuous 0xc7 (NWK_TABLE_FULL) and 0xcd (NWK_NO_ROUTE) errors. The packet processing bottleneck is an internal firmware failure within the Z-Stack core, not the serial interface. 2. Enterprise Constraints &amp; TI&#39;s Responsibility Your recommendation to increase MAC_CFG_TX_MAX / RX_MAX 10x and expand NPI_TL_BUF_SIZE to 1024 bytes is the correct path. But as an end-user operating turnkey hardware like the SM Light SLZB-06P7, I cannot simply recompile the ZNP binary myself. If the standard TI reference examples and SDK defaults are systematically starved for modern network traffic, TI needs to push these optimized compilation parameters (NPI_TL_BUF_SIZE = 1024, UART_ISR_BUF_SIZE = 128, maximized MAC buffers) directly into the upstream SDK branches. It is entirely unacceptable that enterprise customers have to reverse-engineer and fight your core SDK defaults just to achieve basic network stability. 3. The Market Reality: Tuya vs. Texas Instruments The entire internet is littered with users running into this exact &quot;SRSP - AF - dataRequestNoSRSP timeout after 6000ms&quot; loop. You do not need my links; you only need to use Google to see the scale of this issue. I have been dealing with these daily crashes for four weeks now, and my patience has reached its absolute limit. If Chinese manufacturers can build a stable, cloud-tethered Zigbee gateway for 30€ that manages mass-router traffic without breaking a sweat, then a multi-billion dollar semiconductor company like Texas Instruments must be capable of delivering a functional local network stack on a premium chip. 4. Imminent Reputation and Image Damage This thread is being closely monitored by the open-source community, core hardware developers, and enterprise integrators alike. Do not underestimate the severe reputational and image damage TI faces if you continue to stall, offer elementary troubleshooting tips, or make excuses about corporate firewalls while critical production infrastructure locks up. I do not want further explanations, and I do not want workarounds that shift the crash window by a few hours. I expect a concrete, production-ready architectural solution from your senior firmware team immediately. Regards, Dirk Freiherr zu Wilmannsberghttps://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1658992/cc2652p7-critical-z-stack-firmware-bug/6399867Tue, 30 Jun 2026 14:20:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:1d1eae05-8ed7-4ad2-89a3-2455fece7249Ryan Brown1Hi Dirk, [quote userid=&quot;706038&quot; url=&quot;~/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1658992/cc2652p7-critical-z-stack-firmware-bug/6399113&quot;]MAC_CFG_TX_MAX / MAC_CFG_RX_MAX: Usually capped at 5 or 8 buffers in standard TI reference examples[/quote] The standard TI reference examples are not optimized for large network traffic. As you have the RAM allowance I would recommend increasing these values 10x like in Koen&#39;s firmware patch . It would be good to evaluate their pre-built images to determine if their configuration is beneficial towards your system. There are also changes to the NPI TL, other definitions, etc. that you could benefit from. Are you using a UART baud rate of 921600 instead of 115200? [quote userid=&quot;706038&quot; url=&quot;~/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1658992/cc2652p7-critical-z-stack-firmware-bug/6399113&quot;]NPI_TL_BUF_SIZE: Typically allocated at 256 bytes in standard ZNP builds[/quote] Please try to increase this to 1024, and UART_ISR_BUF_SIZE to 128. The heap manager auto size configuration is acceptable. You could try implementing NPI flow control (NPI_FLOW_CONTROL) to handshake messages but this would require additional RTS/CTS UART pins. [quote userid=&quot;706038&quot; url=&quot;~/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1658992/cc2652p7-critical-z-stack-firmware-bug/6399113&quot;]The packet has already penetrated the radio layer, crossed the MAC layer, and flooded the internal OSAL buffer queue of the CC2652P7 before MT_AF_INCOMING_MSG is even pushed over the serial port.[/quote][quote userid=&quot;706038&quot; url=&quot;~/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1658992/cc2652p7-critical-z-stack-firmware-bug/6399113&quot;]The Z-Stack crashes internally from the SRSP queue overflow before the host application has a chance to drop the message.[/quote][quote userid=&quot;706038&quot; url=&quot;~/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1658992/cc2652p7-critical-z-stack-firmware-bug/6399225&quot;]Yet, look at the live Zigbee2MQTT logs: The Z-Stack is continuously getting pounded by &quot;genTime.readRsp&quot; bursts[/quote] I figured it would help to reject unwanted read responses from being sent to the host and further taxing the UART communication, however it is understood that these messages would still waste processing by the Zigbee stack before being dropped. [quote userid=&quot;706038&quot; url=&quot;~/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1658992/cc2652p7-critical-z-stack-firmware-bug/6399113&quot;]With all due respect, telling an enterprise customer to forcefully eject stable, industrial-grade routing hardware from a production mesh because the Z-Stack cannot handle standard ZCL time-sync requests is not a viable architectural mitigation[/quote][quote userid=&quot;706038&quot; url=&quot;~/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1658992/cc2652p7-critical-z-stack-firmware-bug/6399225&quot;]We do not need basic troubleshooting tips or suggestions to eject stable routers from our safety-critical infrastructure.[/quote] I apologize for the suggestion and will not recommend this in further communications. [quote userid=&quot;706038&quot; url=&quot;~/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1658992/cc2652p7-critical-z-stack-firmware-bug/6399225&quot;]We need senior firmware engineers to adjust the ZNP compilation parameters, maximize the internal buffer structures to match the physical 124 kB RAM capacity of the CC2652P7, and eliminate this heap exhaustion loop. Furthermore, TI needs to coordinate these firmware optimizations directly with core hardware integrators like SM Light, so that patched, production-ready ZNP binaries can be pushed to end-users as an immediate update.[/quote][quote userid=&quot;706038&quot; url=&quot;~/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1658992/cc2652p7-critical-z-stack-firmware-bug/6399225&quot;]If Texas Instruments is lack of engineering personnel or technically unable to fix this legacy memory management architecture in a timely manner, it is time to open-source the Z-Stack core repository entirely. The open-source community would gladly fix this persistent heap-exhaustion bug within a week, rather than leaving enterprise customers stranded with critical infrastructure lockups.[/quote] I understand that such action would greatly benefit the community, as I do not have such authority or permissions I have given your feedback to management for further consideration. [quote userid=&quot;706038&quot; url=&quot;~/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1658992/cc2652p7-critical-z-stack-firmware-bug/6399225&quot;]Complete Network Metrics &amp; LQI Gallery: postimg.cc/.../Y7h3t6t [/quote] I am not able to view this link due to firewall restrictions. Regards, Ryanhttps://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1658992/cc2652p7-critical-z-stack-firmware-bug/6399225Tue, 30 Jun 2026 05:19:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:891222ce-933b-467b-9117-5f997275a656Dirk Freiherr zu WilmannsbergHi Ryan, To back up my technical analysis with hard data and clear architectural proof, please see the attached logs and network metrics from this production environment. As you can observe in the network overview screenshots, the physical mesh is completely healthy, highly optimized, and incredibly stable on the RF layer. Out of all 120 active devices (111 high-volume routers and 9 end devices), the vast majority of the routing backbone maintains a flawless Link Quality Indicator (LQI) deep in the triple-digit range—with widespread values between 100 and over 160. Even the Eglo lamps maintain solid, high LQI connections because they are exclusively triggered via optimized Zigbee groups. This pristine connection quality is a direct result of strict infrastructure planning, precise transmit power tuning to a -7 Sweet Spot, and meticulous deployment. Yet, look at the live Zigbee2MQTT logs: The Z-Stack is continuously getting pounded by &quot;genTime.readRsp&quot; bursts. Because the internal buffers and execution contexts are completely exhausted under this concurrent routing load, the stack drops paths and throws &quot;NWK_NO_ROUTE (0xcd)&quot; errors. Let&#39;s be completely transparent about what is happening here: This exact, high-density mesh network previously ran for over six months without a single crash or freeze when connected to a cheap, $30 Tuya/Tongu LAN gateway using a basic Silicon Labs chipset. We migrated this infrastructure to a dedicated CC2652P7 coordinator specifically to achieve local, mission-critical independence, expecting enterprise-grade stability from Texas Instruments hardware. Instead, we are met with a catastrophic software failure. To put it in plain architectural terms: The Z-Stack&#39;s current memory management behaves like a pedestrian walking down the street, diligently collecting pieces of dog waste, but instead of disposing of them, they stack them up sequentially into a massive pile right in the middle of the road until the entire street becomes completely impassable. This is exactly how the Z-Stack treats asynchronous cluster requests. It collects frames, fails to clear the expired or completed execution contexts from the internal OSAL tables, and lets the data pile up until the internal serial interface hits the fatal 6000ms SRSP lockup. This is not an edge-case or a hardware limitation. This is a severe architectural flaw in how the Z-Stack handles high-volume application-layer traffic. We do not need basic troubleshooting tips or suggestions to eject stable routers from our safety-critical infrastructure. We need senior firmware engineers to adjust the ZNP compilation parameters, maximize the internal buffer structures to match the physical 124 kB RAM capacity of the CC2652P7, and eliminate this heap exhaustion loop. Furthermore, TI needs to coordinate these firmware optimizations directly with core hardware integrators like SM Light, so that patched, production-ready ZNP binaries can be pushed to end-users as an immediate update. A simple web search for the &quot;SRSP - AF - dataRequest after 6000ms&quot; timeout proves that the global smart home and industrial automation community is plagued by this exact core flaw. If Texas Instruments is lack of engineering personnel or technically unable to fix this legacy memory management architecture in a timely manner, it is time to open-source the Z-Stack core repository entirely. The open-source community would gladly fix this persistent heap-exhaustion bug within a week, rather than leaving enterprise customers stranded with critical infrastructure lockups. Complete Network Metrics &amp; LQI Gallery: postimg.cc/.../Y7h3t6t Regards, Dirkhttps://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1658992/cc2652p7-critical-z-stack-firmware-bug/6399113Tue, 30 Jun 2026 03:09:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:16c6ccbb-fe29-4de6-88ec-58e62c44dea1Dirk Freiherr zu WilmannsbergHi Ryan, To answer your initial question: I am currently managing this infrastructure directly, without a dedicated TI Field Office contact, which is why I am raising this directly to the E2E engineering platform. Let’s address the core configuration parameters you mentioned. Since this deployment runs on top of the Zigbee2MQTT/ZNP architecture (based on Koen Kanters&#39; Z-Stack firmware compilation), the firmware runs as a ZNP (Zigbee Network Processor) application. Here are the critical compile-time values of the Z-Stack definitions you asked about: * NPI_TL_BUF_SIZE: Typically allocated at 256 bytes in standard ZNP builds. This is exactly where the bottleneck starts when 31 industrial-grade routers stream high-frequency measurement attributes alongside concurrent ZCL time-sync requests. The transport layer buffer simply overflows before the serial interface can flush it to the host. * MAC_CFG_TX_MAX / MAC_CFG_RX_MAX: Usually capped at 5 or 8 buffers in standard TI reference examples. In a high-density 111-router mesh, this allocation is fundamentally insufficient to absorb transient ZCL spikes. * HEAPMGR_SIZE: Set to 0 (auto-size dynamic heap) in these large-RAM P7 configurations to utilize the 124 kB RAM. However, OSAL dynamic memory allocation suffers from severe fragmentation under continuous asynchronous load, leading to a silent heap exhaustion despite physically available memory. Let&#39;s clarify one crucial point: Transient errors like NWK_TABLE_FULL or dropped reporting packets do not cause the crash. The actual, system-stopping failure is the fatal &quot;SRSP - AF - dataRequest after 6000ms&quot; timeout. When the application layer queues clog up with genTime queries, they pile up exponentially until the Z-Stack&#39;s synchronous interface completely locks up. Once this 6000ms SRSP timeout threshold is crossed, the internal serial/UART driver chokes, rendering the entire CC2652P7 unresponsive until a hard hardware power cycle is performed. Regarding your mitigation suggestions: 1. Filtering via MT_AfIncomingMsg: Since this is a ZNP-compiled binary architecture, filtering incoming cluster requests (like genTime) on the host application layer (Zigbee2MQTT) comes too late. The packet has already penetrated the radio layer, crossed the MAC layer, and flooded the internal OSAL buffer queue of the CC2652P7 before MT_AF_INCOMING_MSG is even pushed over the serial port. The Z-Stack crashes internally from the SRSP queue overflow before the host application has a chance to drop the message. 2. Forcing misbehaving routers to leave the network: With all due respect, telling an enterprise customer to forcefully eject stable, industrial-grade routing hardware from a production mesh because the Z-Stack cannot handle standard ZCL time-sync requests is not a viable architectural mitigation. Removing routers destroys the mesh path topology and compromises the safety-critical infrastructure relying on those exact routing chains. The Concrete Request to TI Engineering: Since you confirmed that TI has no current plans to modify the Z-Stack core source code to gracefully drop outbound TX buffers or throttle incoming traffic, we must optimize the buffer allocations within the existing codebase. Given that the CC2652P7 provides a massive 124 kB of RAM, the standard reference limits inherited from older CC2652R (80 kB) configurations are artificially choking the hardware. Please consult with a Senior Z-Stack Systems Engineer and provide specific, stable compile-time recommendations for NPI_TL_BUF_SIZE, MAC_CFG_TX_MAX, and specific OSAL heap tweaks to explicitly scale the memory allocation to the CC2652P7’s full physical capacity. If TI cannot patch the source code, you must guide us on how to safely maximize these internal buffers to prevent the serial interface from hitting that fatal 6000ms SRSP lockup under ZCL high-volume conditions. Regards, Dirkhttps://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1658992/cc2652p7-critical-z-stack-firmware-bug/6398122Mon, 29 Jun 2026 12:40:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:a634e205-4d51-4165-a0dd-09e983fc7624Ryan Brown1Hi Dirk, Are you in contact with a TI Field or Sales office? In order to best address your questions, I need to know what SDK version you are using and whether you&#39;ve applied Koen&#39;s recommended changes. Is your project using a ZNP or ZC application? In particular, what are the values of the following definitions? NPI_TL_BUF_SIZE MAC_CFG_*_MAX HEAPMGR_SIZE You could choose to utilize application processing in MT_AfIncomingMsg or processAfIncomingMsgInd (depending on ZNP or ZC) to filter out unwanted ZCL messages. Or you could proactively have the ZC request that &quot;misbehaving third-party routers&quot; leave the network and prevent them from re-joining. There is no current plan to modify the Z-Stack source code to filter incoming requests or drop packets in the TX buffer, so we will need to mitigate this behavior from the application as best as possible. Regards, Ryanhttps://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1658992/cc2652p7-critical-z-stack-firmware-bug/6397333Sat, 27 Jun 2026 09:04:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:40289378-53b4-4fc7-a67a-2d8d14ff0b63Dirk Freiherr zu WilmannsbergTechnical details regarding the Z-Stack crash under high-density ZCL traffic on CC2652P7 Hi Ryan, Thank you for the response. To prevent the usual &#39;edge-case&#39; or &#39;out-of-spec&#39; assumptions, let me provide you with the exact technical environment and the protocol-level behavior that triggers this critical Z-Stack freeze. 1. The Environment (High-Density Enterprise Mesh) - Coordinator: SMLIGHT SLZB-06P7 based on the CC2652P7 chip (124 kB RAM available for Z-Stack). - Network Size: 120 physical Zigbee devices (111 Routers, 9 End Devices). - Traffic Profile: 31 of these routers are industrial-grade smart breakers that constantly stream energy metrics (Voltage, Current, Power) back to the coordinator via reporting. 2. The Trigger Condition (The &quot;ZCL Time-Sync Spam&quot;) The crash is reliably triggered when a specific brand of light bulbs (Manufacturer: Eglo/AwoX) floods the coordinator with ZCL time cluster read requests (genTime.readRsp) every few seconds. 3. The Z-Stack Failure Mode (Why this is a Core Bug) When the high frequency of incoming energy metrics coincides with the rapid generation of genTime responses by the coordinator, the serial transmit buffer of the Z-Stack completely clogs up. Instead of gracefully dropping unacknowledged or low-priority packets, the Z-Stack exhibits the following behavior: - Latency Spike: ZCL command response latency suddenly jumps from &lt;100 ms to over 6000 ms. - Serial Backlog: The communication between the Zigbee core and the serial interface (UART/Network bridge) freezes. - Fatal Lockup: The CC2652P7 chip stops responding entirely. It requires a hard power cycle (physical voltage cutoff via relay) to recover. A warm software reset is often not enough because the internal heap/NV-RAM state remains corrupted. 4. The Question to TI Engineering As a software engineer, I see a clear architectural flaw in how the Z-Stack handles asynchronous traffic peaks on the Application Layer. - Why does the Z-Stack allow the serial/ZCL response buffer to completely exhaust the 124 kB RAM instead of throttling incoming requests or dropping expired outbound packets? - Is there a hidden buffer allocation limit within the f8wConfig.cfg or the Z-Stack core that causes a silent stack overflow when processing high-volume genTime requests alongside standard attribute reports? We need a patch or a compiler flag recommendation to harden the Z-Stack against this type of Application-Layer Denial of Service (DoS) caused by misbehaving third-party routers. Looking forward to your deeper technical analysis.https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1658992/cc2652p7-critical-z-stack-firmware-bug/6396770Fri, 26 Jun 2026 15:09:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:f72cc47a-a4e0-455f-a751-54d8898cda1aRyan Brown1Hi Dirk, Please provide the SimpleLink F2 SDK version you are evaluating, as well as any debug or sniffer logs if you have them. Are you using the Zigbee2MQTT ZNP patches and can you provide further details as to this version as well? Koen Kanters and I engaged on this topic a few years ago, here are the references: SIMPLELINK-CC13X2-26X2-SDK: Firmware not stable since SDK 6.20.00.29 https://github.com/Koenkk/Z-Stack-firmware/discussions/483 https://github.com/Koenkk/Z-Stack-firmware/discussions/496 Regards, Ryanhttps://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1658992/cc2652p7-critical-z-stack-firmware-bugFri, 26 Jun 2026 11:16:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:c7aa1a43-ba24-4bad-8d72-b1f042a79796Dirk Freiherr zu WilmannsbergOther 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&#39;s internal memory management for &#39;AF - dataRequest&#39; 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 &quot;SRSP AF&quot; 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.CC2652P7CC2652PZ-StackCC2652Rhttps://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1656957/cc2652p-red-certification-tests/6391944Tue, 23 Jun 2026 13:25:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:602d21c5-5ceb-4086-8612-345192a984bfRoberto NuceraVery kind of you! BR Luigihttps://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1656957/re-cc2652p-zigbee-fragment-can-t-receive-the-fragment-packet-with-0xff-dstendpoint-in-sdk-8-30/6389027Fri, 19 Jun 2026 13:54:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:17e7f84d-dd71-4806-927a-f10080a468caRyan Brown1Hi Luigi, The options made available by TI are 1) Smart RF Studio 7 ,which required a JTAG connection and communicates using ROM commands which do not require the device to be programmed in any particular way, or 2) program the rfDiagnostics example on your device and use AT commands through the UART connection to configure the radio and start test modes. Either will meet all of your requirements, whichever you select depends mostly on your desired interface. Regards, Ryanhttps://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1656957/cc2652p-red-certification-testsFri, 19 Jun 2026 06:59:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:e2f3ed84-045d-4cec-95ba-9d84ec93f214Roberto NuceraOther Parts Discussed in Thread: CC2652P , Z-STACK , CC2652P7 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 LuigiCC2652P7CC2652PZ-Stackhttps://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1653445/cc2340r5-the-cc2350r53-zboss-zigbee-how-to-achieve-a-network-scale-of-128-nodes/6387621Thu, 18 Jun 2026 12:24:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:09430377-e254-4437-9c7c-6b951b3db271Ryan Brown1I do not see the OTA packet logs attached, and the C/R.txt files only include the LogModule_Zigbee_OSIF which details NVRAM. Could you enable LogModule_Zigbee_Low_Level_MAC and LogModule_Zigbee_App as well with all Levels selected (DEBUG, VERBOSE, INFO, WARNING, &amp; ERROR)? It would be helpful to have gc_neighbor_table_size alongside the total NWK capacity. Are the ZR allowed to join the Zigbee network through other ZR and form a mesh, or are they all trying to directly connect to the ZC? What are the ZR devices, TI EVMs or third-party modules? I assume this test with run with a NVS region size of 0x4000, would the behavior change if it was increased to 0x6000 or 0x8000? Can you verify in the memory window of a debug session whether your NVS memory is filled? Previously you had only reported 31 devices joining; do you know what changed? Regards, Ryanhttps://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1653445/cc2340r5-the-cc2350r53-zboss-zigbee-how-to-achieve-a-network-scale-of-128-nodes/6387070Thu, 18 Jun 2026 04:31:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:d1eaab5e-d818-4187-af6b-39336feb6aa0baosong xiee2e.ti.com/.../C.txt e2e.ti.com/.../R.txthttps://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1653445/cc2340r5-the-cc2350r53-zboss-zigbee-how-to-achieve-a-network-scale-of-128-nodes/6387046Thu, 18 Jun 2026 04:02:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:348b31b2-9eb6-427b-8d0c-54b636304be6baosong xieWe obtained the total capacity of the network through the interface &quot;zb_nwk_get_total_capacity()&quot;, and it is exactly 100 the value set by SYSCFG.https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1653445/cc2340r5-the-cc2350r53-zboss-zigbee-how-to-achieve-a-network-scale-of-128-nodes/6387044Thu, 18 Jun 2026 03:51:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:f86772aa-400f-4720-b5b5-bbb640b059a1baosong xieWe conducted tests on version V9.20（simplelink_lowpower_f3_sdk_9_20_00_81），The &quot;Network Maximum Children&quot; parameter in SYSCFG is configured as 100 and The &quot;Network Maximum End Device Capacity&quot; parameter in SYSCFG is configured as 50. Build a Zigbee R23 network consisting of 50 routers,the routing nodes are connected to the network one by one, When the 44th router node is connected to the network, it cannot join the network. Then we powered off the 43 previously connected router nodes and focused solely on the network connection process of the 44th router node. We obtained the log files of the Zigbee frames in the air，and obtained the serial port logs of the coordinator and the 44th router node.https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1656024/cc26xx-resources-matter-v-1-5---not-able-to-find-support-for-cc2652r7/6386031Wed, 17 Jun 2026 13:12:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:220e0fa2-4bf0-46da-ace9-c48c1ba9f75bRyan Brown1Hi Adesh, TI is currently in the process of certifying our Thread 1.4 and Matter 1.5 solution by September 2026. However, this will be performed for CC2755xx platform and all variants. In truth the CC2652R7 does not have enough flash memory to act as a Matter end device but could perform the task of a Thread RCP for a Matter fabric controller. TI has enabled an evaluation ready software support via down-stream forks of Open Thread and Matter . Regards, Ryan