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/1635277/cc2652p-which-file-can-change-tx_power-bootloader-backdoor-dio-and-lf-clock-source/6303815Fri, 10 Apr 2026 13:11:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:83139d53-cdf2-4c0d-9f7d-9deebfbdc4c3Ryan Brown1Hi Kimi, These are achieved through modification of the openthread.syscfg file, preferably by using the standalone SysConfig tool . Custom -&gt; IEEE -&gt; TX power Device Configuration -&gt; Enable Bootloader / Backdoor Device Configuration -&gt; LF Clock Source Regards, Ryanhttps://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1635277/cc2652p-which-file-can-change-tx_power-bootloader-backdoor-dio-and-lf-clock-sourceFri, 10 Apr 2026 10:18:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:7e93ec27-458e-467f-8d9f-c5a5cf4705e1Kimi HuPart Number: CC2652P Hi, I downloaded OpenThread from your GitHub repository ( https://github.com/TexasInstruments/ot-ti ). I need to change some parameters. Could you please tell me which files I should modify? TX_POWER Bootloader Backdoor DIO &amp; Trigger Level of Bootloader Backdoor LF Clock SourceCC2652Pbuilding automationSYSCONFIGhttps://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1631149/cc2745r10-q1-is-there-a-way-to-use-can-fd-on-cc2745-without-freertos/6302057Thu, 09 Apr 2026 13:12:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:924ae50e-049a-44c1-b044-ae275097c89aChristin LeePlease do not post the same question on multiple forums. I will close this one and respond on Bluetooth LE forumhttps://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1634057/cc2652p-cc2652p-sonoff-zigbee-3-0-dongle-plus-sends-nwk-key-but-ignores-aps-request-key-tclk-and-secure-rejoin-request/6300373Wed, 08 Apr 2026 13:39:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:752e978d-b9cc-4866-bd82-4e8ed229c591Ryan Brown1Hi Elisavet, I have no experience with the zigpy ZNP build or usage. Have you considered asking their GitHub space for support? Do you have print logs on the ZNP messages as well as sniffer logs of the over-the-air communication? You could try loading and using the default znp example from the SimpleLink F2 SDK. You may also reference the Monitor and Test API guide as well as Z-Tool instructions for commissioning. What kind of device are you trying to join and have you tried joining any other devices (even another CC2652P dongle with ZED/ZR application code loaded)? If you have the ZNP project you could try to debug ZDSecMgrRequestKeyInd -&gt; ZDSecMgrTclkReq to further determine the reason for key transport failure. If the TCLK update procedure is required then this must occur before security and address tables are fully populated I know little of APS_UPDATE_DEVICE as it is not a Z-Stack term, perhaps this comes from zigpy Here is some more information from zglobals.c, I also encourage you to read through the Z-Stack User&#39;s Guide . // With changes introduced in R20 of the ZigBee specification, // boolean value of zgUseDefaultTCLK is set depending on zgApsLinkKeyType value. // // For zgApsLinkKeyType = ZG_GLOBAL_LINK_KEY, zgUseDefaultTCLK = TRUE // For zgApsLinkKeyType = ZG_UNIQUE_LINK_KEY, different devices have // different value: // ZC should have zgUseDefaultTCLK = FALSE // Other devices should have zgUseDefaultTCLK = TRUE // This is initialized in zgInitItems() // If ZG_UNIQUE_LINK_KEY, individual trust center link key between each device // and the trust center should be manually configured via MT_SYS_OSAL_NV_WRITE Only if bdbTrustCenterRequireKeyExchange from bdbAttributes_t is FALSE If TCLK updates are required then this could also be a limitation to secure rejoin requests Regards, Ryanhttps://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1634153/cc2755p10-cc2755---need-help-with-power-rails/6300128Wed, 08 Apr 2026 10:58:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:b5ae5487-91d4-408b-8e3c-5d8e6a9030fdRGWHi, The IC will work at 1.8 V. In Global LDO Mode (GLDO), the voltage operating range is 1.71 V - 3.80 V. The DCDC mode works from 2.2 V - 3.8 V; if the voltage (VDDS) drops below 2.2 V then the chip switches to GLDO mode. For optimum current consumption, ideal to keep the VDDS supply as high as possible to utilize the inbuilt DCDC converter and to use the VDDIO as 1.8 V for split-rail supply. Alternatively, power everything with just 1.8 V.https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1632762/cc2674p10-enabling-20dbm-for-znp-on-cc2674p10-rgz/6299648Wed, 08 Apr 2026 05:15:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:623c3462-f633-4e0d-8ecf-0b46b354df84Shuyang ZhongHi Ryan, I have verified the antenna switching pin is toggling as expected and the software goes into the high PA branch in the antenna switching callback. Thanks for confirming and I will work with the customer to verify the behavior on their end. Best regards, Shuyanghttps://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1634153/cc2755p10-cc2755---need-help-with-power-railsWed, 08 Apr 2026 03:24:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:c0e1e813-7fc3-49a8-ad9d-08e605b4678dNarashiman PPart Number: CC2755P10 Hi, I am trying to build an IOT device using CC2755. Will the IC work with 1.8V . I think there would be minor choking with &lt;2.2V. Correct me if i am wrong. Also, in that case is there any way we can make the GPIO pins work at 1.8V instead of 3.0 or 3.3V .CC2755P10Portable Electronicshttps://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1632762/cc2674p10-enabling-20dbm-for-znp-on-cc2674p10-rgz/6299028Tue, 07 Apr 2026 19:00:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:001904b5-9fa8-462c-af7f-27dc44a8e7e7Ryan Brown1Based on my quick test it appears that the TX powers in between +14 and +20 dBm can be selected using SYS_SET_TX_POWER and determine the TX output power of the default CC2674P10 ZNP project where a network has been formed. I can observe packet RSSI modulating as expected and observed in a packet sniffer when changing TX power values. Values from -20 to +5 dBm are not included in txPowerTable_2400_pa20 and thus not supported. Regards, Ryanhttps://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1634057/cc2652p-cc2652p-sonoff-zigbee-3-0-dongle-plus-sends-nwk-key-but-ignores-aps-request-key-tclk-and-secure-rejoin-requestTue, 07 Apr 2026 17:55:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:58c7103b-cacc-468f-97a0-028e3e9ed307Elisavet PapadopoulouPart Number: CC2652P Other Parts Discussed in Thread: Z-STACK Hello, I am working with a Sonoff Zigbee 3.0 USB Dongle Plus (CC2652P coordinator running Z-Stack 3.x via ZNP). I am developing a custom Zigbee node implementation (not based on TI Z-Stack) and investigating Trust Center admission behavior. My device successfully performs the following sequence: MAC Association Request → Association Response received APS Transport Key (network key) received from the coordinator ZDO Device Announce is broadcast by the coordinator So the device clearly joins the network at NWK level and receives the network key successfully. However: APS Request Key (key type = 0x04, Trust Center Link Key) is only MAC-ACKed and never answered Secure NWK Rejoin Request is only MAC-ACKed and never answered No APS_UPDATE_DEVICE command is observed The joining device does not appear in coordinator-side key tables Coordinator security configuration (from ZNP/zigpy network info): APS_USE_INSECURE_JOIN = 1 USE_DEFAULT_TCLK = 1 SECURE_PERMIT_JOIN = 1 APS_LINK_KEY_TABLE empty TCLK_TABLE empty Device capability flags during association: alternate_pan_coordinator = 0 device_type = 0 (end device) receiver_on_when_idle = 1 security_capability = 1 allocate_address = 1 Zigbee revision = 22 Observed behavior summary: NWK Transport Key is delivered successfully Device Announce is rebroadcast by coordinator APS Request Key (0x04) ignored Secure Rejoin Request ignored Only MAC ACK responses received No APS_UPDATE_DEVICE observed at any stage Questions: After NWK Transport Key delivery and Device Annouce, under what conditions does Z-Stack 3.x (CC2652P coordinator) insert the device into ADDRMGR / security tables? Is APS_UPDATE_DEVICE required before APS Request Key (0x04) is accepted? Does USE_DEFAULT_TCLK = 1 suppress Trust Center link-key transport entirely in Zigbee 3.0 mode? Can a device that successfully received the NWK key still be considered unauthenticated at APS level? Are additional conditions required before Secure NWK Rejoin Request is answered? Any clarification on Trust Center admission policy in this scenario would be greatly appreciated.CC2652PZ-StackTest &amp; Measurementhttps://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1632762/cc2674p10-enabling-20dbm-for-znp-on-cc2674p10-rgz/6296872Mon, 06 Apr 2026 14:14:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:3f12e572-c0c3-472d-adec-16ff75100178Ryan Brown1Hi Shuyang, Please confirm the SimpleLink F2 SDK version being used and provide the ti_radio_config.c/h files being generated by SysConfig. How is the customer verifying the output TX power, and are they evaluating it both before and after commissioning? Please also try the following: Revert ZMacSetZigbeeMACParams, copy ti_zstack_config.h from the syscfg output folder to the root project directory, disable ti_zstack_config.h from generating in the SysConfig editor, and edit TXPOWER in the root ti_zstack_config.h to 20. Use SYS_SET_TX_POWER to change different TX powers (0, +5, +15, +19, +20) both before and after commissioning, and report the result of each I cannot comment on the definition of ZMacTransmitPower_t. You should not have to specify the paType manually. I am not able to test today but will try to find a CC2674P10 RGZ tomorrow to evaluate. Regards, Ryanhttps://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1632762/cc2674p10-enabling-20dbm-for-znp-on-cc2674p10-rgz/6295868Fri, 03 Apr 2026 08:26:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:21ed2d81-f49c-4e90-9ad6-31ee2f7476f9Shuyang ZhongHi Ryan, The customer tried to modify the Tx power passed into ZMacSetTransmitPower(), but the Tx power is not changed. Two questions about this function: 1. ZMacTransmitPower_t only contains enums up to 19, but ZMacSetTransmitPower seems to accept an input parameter of 20 because the return value is 0(SUCCESS) when (ZMacTransmitPower_t)20 is passed into it. I&#39;m a little confused about the enum definition, why it is up to 19 not 20? 2. The customer has verified the return value of ZMacSetTransmitPower() being 0, but in antenna callback function, it still is not hitting the if (paType == RF_TxPowerTable_HighPA) branch. Is there anything else needed besides changing the Tx power? Do I need to specify the paType manually? If you happen to have a CC2674P10 board on hand, it will be really appreciated if you give us a hand to verify it on your side, thanks. Best regards, Shuyanghttps://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1632762/cc2674p10-enabling-20dbm-for-znp-on-cc2674p10-rgz/6294751Thu, 02 Apr 2026 14:07:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:1d26073b-b7fc-4811-ba7d-f26836daaa7cRyan Brown1Hi Shuyang, I&#39;ve investigated and do not think the Migration Guides will offer much clarity in this regard. When looking at the znp_LP_EM_CC2674P10_tirtos7_ticlang ti_radio_config.c/h SysConfig-generated files, it appears that the high PA tables are already available. There is likely an error in the Zigbee SysConfig module which only allows non-PA values, which you could amend by replacing TXPOWER in ZMacSetZigbeeMACParams /******************************************************************************************************** * @fn ZMacSetZigbeeMACParams * * @brief Sets MAC PIB values specific for Z-Stack (after calling ZMacReset) * * @return None ********************************************************************************************************/ void ZMacSetZigbeeMACParams(void) { uint8_t responseWaitTime = 16; ZMacSetReq(MAC_RESPONSE_WAIT_TIME, &amp;responseWaitTime); uint16_t transactionPersistenceTime = 500; ZMacSetReq(MAC_TRANSACTION_PERSISTENCE_TIME, (byte *)&amp;transactionPersistenceTime); uint8_t macFrameRetries = ZMAC_MAX_FRAME_RETRIES; ZMacSetReq(MAC_MAX_FRAME_RETRIES, &amp;macFrameRetries); ZMacSetTransmitPower( (ZMacTransmitPower_t)20 ); //CHANGED FROM TX_POWER } You could also use the SYS_SET_TX_POWER MT API during runtime. Regards, Ryanhttps://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1632762/cc2674p10-enabling-20dbm-for-znp-on-cc2674p10-rgzThu, 02 Apr 2026 07:21:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:f53b7b2b-85a2-481c-960d-e013d497e0dbShuyang ZhongPart Number: CC2674P10 Other Parts Discussed in Thread: SYSCONFIG My customer is using a custom board with CC2674P10 RGZ, they would like to enable the 20dBm Tx power on ZNP project, but could not find how to. znp_LP_EM_CC2674P10_tirtos7_ticlang only supports maximum 5dBm: And switching device is not supported in the project of LP_EM_CC2674P10. I also tried to start from a LP_EM_CC1354P10-6 project, but there is no option for CC2674P10 RGZ in the device switching window: Please kindly provide a guide to enable the 20dBm Tx power for ZNP project, the target device is CC2674P10 RGZ. Thanks. Best regards, Shuyangbuilding automationCC2674P10SYSCONFIGhttps://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1630989/cc2755p10-cc2755p10-cc2745r10-output-power-drops-and-harmonics-increase-above-a-certain-power-threshold/6291212Tue, 31 Mar 2026 15:11:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:c52890e0-97dc-4145-9d30-844a7536acb2desouzaHi, Thanks for the additional details. This morning I tested two Launchpad boards featuring both the CC2745R10-Q1 and the CC2755P10 from 5 to 10dBm and I did not see the loss of power issues reported. I did not test harmonics as the performance did not deviate from the expected power as shown in the LP-EM-CC2745R10-Q1 certification reports . The mode flag in the PA table switches between the +5 and the +20dBm PA for the upper power levels, which explains that you are seeing the difference exactly in the transition between +5 (max power of the regular path) and +6 when the other PA is re-routed. In the light of this, I can&#39;t help but wonder that your VDDR line may be sagging when the higher output power is enabled. The reason is that the +20dBm PA is powered by VDDR when used at power up to +10dBm. If your VDDR supply has any issues (typically the output of the DCDC converter), the problem might happen due to lack of power. I attached the entirety of measurements done this morning for various tests. Hope this helps, Rafael e2e.ti.com/.../1321.CC27x5x10.ziphttps://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1630989/cc2755p10-cc2755p10-cc2745r10-output-power-drops-and-harmonics-increase-above-a-certain-power-threshold/6289230Mon, 30 Mar 2026 15:11:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:c0e69e89-9c46-47af-aafe-d7f9cbd6b4b1Tiago LoneWe are using SmarRF Studio v1.3.2 Selecting LP-EM-CC2745R10-Q1 profile, using SmartRF Studio 8 v1.3.2: setting output +5 dBm, conducted measurement = +5 dBm, and double frequency harmonic around -50 dBc. setting output +6 dBm, conducted measurement = 0 dBm, and 2nd harmonic significantly increased to -35 dBc. setting output +10 dBm, conducted measurement = +4.5 dBm, and 2nd harmonic continues around -35 dBc. Project works perfectly at +5dBm output, but trying to increase even to +5.5dBm is &quot;tragic&quot;. And all devices are marked with the letter &quot;F&quot; on its package . See photos below:https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1630989/cc2755p10-cc2755p10-cc2745r10-output-power-drops-and-harmonics-increase-above-a-certain-power-threshold/6289027Mon, 30 Mar 2026 13:22:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:1ad9289c-ede1-410c-8e12-68b929481c60desouzaHi, Thanks for the clarification. Indeed it seems the PA table is negatively influencing the output power at higher levels. One important question I forgot to ask: what version of SmartRF Studio 8 do you have? There were revisions to the PA table starting with version 1.3.0 (build 84). Also, which device versions do you have? The PA tables were characterized with PG2.1, which is marked with the letter &quot;F&quot; on its package (check the device&#39;s errata at its product pages: CC2755P10 , CC2745R10-Q1 ) I will keep investigating this and report back any findings that may corroborate or help overcome the issues you are seeing. In any case, please consider acquiring a Launchpad board to make comparisons, which help us also further investigate this on our end as well. Regards, Rafaelhttps://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1631149/cc2745r10-q1-is-there-a-way-to-use-can-fd-on-cc2745-without-freertosMon, 30 Mar 2026 02:04:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:4088b6bd-f856-4c38-b033-06fac162ecaazeng wangPart Number: CC2745R10-Q1 Background: Currently, we are using the CC2745 chipset and developing based on the SDK: simplelink_lowpower_f3_sdk_9_14_00_41 . We found that the CAN FD driver in this SDK requires FreeRTOS. Besides the simplelink_lowpower_f3_sdk_9_14_00_41 , is there any other library or SDK that supports CAN FD functionality properly without relying on FreeRTOS? If simplelink_lowpower_f3_sdk_9_14_00_41 is the only available SDK, are there any other methods to use CAN FD without FreeRTOS while maintaining normal functionality?CC2745R10-Q1https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1630989/cc2755p10-cc2755p10-cc2745r10-output-power-drops-and-harmonics-increase-above-a-certain-power-threshold/6287785Fri, 27 Mar 2026 21:01:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:328d05db-63ad-4b17-8100-e4addf9c1a6cTiago LoneThank you for the detailed response and the attached RF path information for the CC2755P10. To confirm: all our measurements are conducted, using a Rohde &amp; Schwarz spectrum analyzer. We are not dealing with antenna or irradiated measurement effects. We appreciate the suggestion regarding stackup and CPWG dimensions, and we will review our design against the reference. However, we would like to highlight why we believe a passive component or layout deviation is unlikely to be the root cause in our case. The power drop we observe is not a gradual degradation, it is an abrupt, systematic drop of 5 dBm or more that occurs precisely at the boundary where the power table transitions to higher mode values, and is consistent across both CC2755P10 and CC2745R10 designs. All entries above that threshold are consistently affected, while all entries below work within expected margins. This does not behave like a gradually worsening match or a component tolerance issue. It leads us to ask: what does the mode field actually switch inside the device? Does it enable a different PA stage, change the RF signal path, or modify internal biasing in a way that could explain this behavior if some condition is not met? Understanding what changes internally when mode goes from 1 to 2 would help us determine whether the root cause is in our hardware or in the configuration. We are also reviewing the attached CC2755P10 RF path details and will follow up if we have further questions on that.https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1630989/cc2755p10-cc2755p10-cc2745r10-output-power-drops-and-harmonics-increase-above-a-certain-power-threshold/6287669Fri, 27 Mar 2026 19:29:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:630c4aa0-f575-426b-9aeb-0becf45a5bffdesouzaHi, Thanks for the comprehensive post. How are you measuring the output power? Are you doing conducted or irradiated measurements? It is preferred to perform conducted measurements as the first step to evaluate the performance of your product without the antenna and any external influences. If your measurements are conducted, then the test environment is properly limited to the device, passive components and the PCB itself. If your measurements above are conducted, what we usually see when loss of power happens is indeed impedance mismatch or a de-tuned output filter. At higher power levels, the RF output is closer to saturation but design deviations can still cause power loss and excessive harmonics. Is your board stackup and CPWG dimensions match the Launchpad? Both devices use the same dimensions on their reference designs. We have also seen that part tolerances and dimensions (we use 0201 passives) caused differences due to added parasitics and coupling, but not as dramatic as you are experiencing. The RF path of the CC2755P10 device has differences when compared to the CC2745R10 - details follow attached to this post. Our datasheet performance figures match our Launchpad reference designs with a reasonable margin (around &#177;2dBm) that accounts for part-to-part variation and manufacturing deviations. In the light of this, I recommend the following: Carefully check your design with our reference design for CC2745R10, especially the stackup and the CPWG dimensions: https://www.ti.com/tool/LP-EM-CC2745R10-Q1#design-files As I mentioned above, the CC2755P10 requires different part values but the routing is identical to the CC2745R10 device. Check the Hardware design application note below, which contains additional design tips outside of the RF path but can still contribute to improve the performance of the device. Available at: https://www.ti.com/lit/pdf/swra834 I suspect you are already experienced in measurements, but still please check our reference guidelines: Measuring current consumption: https://www.ti.com/lit/pdf/swra478 RF testing guidelines: https://www.ti.com/lit/pdf/swra370 For irradiated measurements, the Antenna Selection Guide is a useful reference. Available at: https://www.ti.com/lit/pdf/swra161 As a last resort, you can always submit your design for review (link here ). Hope this helps, Rafael e2e.ti.com/.../mcu124b.pdfhttps://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1630989/cc2755p10-cc2755p10-cc2745r10-output-power-drops-and-harmonics-increase-above-a-certain-power-thresholdFri, 27 Mar 2026 15:31:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:e18cbd29-4029-48b0-8432-e85865ed83bbTiago LonePart Number: CC2755P10 Other Parts Discussed in Thread: LP-EM-CC2745R10-Q1 , SYSCONFIG , CC2745R10-Q1 We are developing a custom board using CC2755P10 and CC2745R10 for IEEE 802.15.4 / Zigbee at 2.4 GHz. We are observing anomalous behavior when RF output power is configured above a certain threshold. The issue is reproducible using SmartRF Studio 8 directly, independently of application firmware. Observed behavior: LP-EM-CC2755P10 profile, SmartRF Studio 8: - +4 dBm: measured = +2 dBm, 2nd harmonic = −50 dBc { .ibBoost=0, .ib=33, .gain=6, .mode=1, .rtrimTxCompCtl=0, .pa20dBmEsdCtl=0, .noIfampRfLdoBypass=0 } - +5 dBm: measured = 0 dBm, 2nd harmonic ~+16 dBm higher than previous step { .ibBoost=0, .ib=54, .gain=3, .mode=2, .rtrimTxCompCtl=0, .pa20dBmEsdCtl=0, .noIfampRfLdoBypass=0 } LP-EM-CC2745R10-Q1 profile, SmartRF Studio 8: - +5 dBm: measured = +5 dBm - +6 dBm: measured = 0 dBm, 2nd harmonic significantly increased - +10 dBm: measured = +4.5 dBm, 2nd harmonic significantly increased Summary: Below a certain power level, both devices behave as expected. Above that threshold, output drops significantly and 2nd harmonic increases by +16 dBm or more and the behavior does not recover at higher configured values either. The anomaly is consistent across CC2755P10 and CC2745R10. Looking at the power table, we noticed this threshold coincides with the point where the mode field transitions from 1 to 2. Entries with mode=2 and mode=3 all show the same anomalous behavior, while entries with mode=1 work as expected. We cannot confirm whether mode is the actual cause or just a correlation, we mention it as an observation. What we have considered: Power table accuracy: We considered the possibility that the default power table generated by SysConfig or SmartRF Studio may contain incorrect values for the higher power entries. However, since both tools generate the table automatically, we have limited ability to evaluate or correct this directly. The only parameter we were able to investigate independently was pa20dBmEsdCtl: we disabled SysConfig generation on our project and manually edited the power table, setting this field to 1 for all mode=2 and mode=3 entries. We observed a marginal improvement (~2 dBm at higher power levels), but the fundamental anomaly persists. This suggests the table may have some inaccuracies, but correcting pa20dBmEsdCtl alone is not sufficient. Supply voltage (VDDS): We considered whether insufficient supply current could explain the behavior. However, project analysis and spot measurements do not indicate a supply issue, and the drop occurs even at low mode=2 levels (5–6 dBm) where current draw should be close to or only marginally higher than the last working mode=1 entries. A supply limitation would not easily explain the abrupt output drop combined with such a large harmonic increase. We mention it for completeness, but consider it unlikely. Impedance matching: We also considered an RF matching issue. However, the CC2755P10 and CC2745R10 integrate the BALUN internally, and our board follows the same RF layout principles as the LP-EM-CC2745R10-Q1 LaunchPad. We have experience with TI CC-family RF projects and proper RF test equipment, which gives us confidence in our measurements and layout analysis. We also note that the LP-EM-CC2755P10 documentation appears in Resource Explorer but links redirect to the CC2745R10-Q1 documentation — so we cannot confirm whether there are relevant schematic or layout differences for the P10 variant. That said, the same anomalous behavior is observed on the CC2745R10 as well, for which we do have access to the correct LaunchPad reference. Following that reference design, we would expect the CC2745R10 to work correctly across its full rated power range — yet the anomaly appears well within that range. The circuit works correctly up to the threshold (~4–5 dBm) on both devices, which makes a matching problem an unlikely explanation for the abrupt change in behavior above that point. As a side note, we would appreciate knowing whether the LP-EM-CC2755P10 schematic differs in any relevant way from the LP-EM-CC2745R10-Q1, or whether they are equivalent for RF purposes, not as the primary concern, but as useful context for our P10 design. We have analyzed the problem as thoroughly as we can from our side and are running out of ideas. Has anyone seen this behavior before? Does anything in our description suggest something we may have overlooked? Are there any additional parameters, initialization steps, or hardware conditions we should investigate? Since we do not have access to a LaunchPad for these devices, we would also be very interested to know if this behavior can be reproduced on one with the default SDK configuration or rfStudio. For reference, below file generated by SysConfig used in most of our tests.. ti_radio_config.c Best RegardsLP-EM-CC2745R10-Q1CC2755P10SYSCONFIGCC2745R10-Q1