Zigbee & Thread forum - Recent Threads

CC2652R7: ZED Unexpected Network Leave + NLME_RestoreFromNV() Returns False

Rafal Wisniowski — Tue, 14 Apr 2026 16:35:03 GMT

Part Number: CC2652R7

Hello,

I'm working on a battery-powered Zigbee End Device (ZED) project and need assistance with two related issues:

Hardware/Software Environment:
- Device: CC2652R7 (custom board)
- Z-Stack Version: 3.x (SDK 8.30)
- Configuration: Zigbee End Device (sleepy end device)

---
Issue 1: Unexplained Network Leave Events

Our battery-powered end devices occasionally leave the Zigbee network unexpectedly (very rare occurrence, ~0.1% of devices in field). Since this is intermittent and difficult to reproduce in our lab, I don't have sniffer logs or device traces yet. I do have information that this issue also happened on older version of SDK (6.20).

Questions:
- What are the known mechanisms that can cause a ZED to leave the network without explicit application request?
- Should I be looking at: parent loss timeout, poll rate issues, security failures, low battery behavior, or something else?
- Are there specific NV items or runtime flags I should monitor to detect why a leave occurred?

---
Issue 2: NLME_RestoreFromNV() Returns False

To work around Issue 1, I'm implementing a network backup/restore mechanism that saves network parameters to a separate custom NVS region. After a device leaves the network, I want to restore the parameters and rejoin the closed network (permit join disabled).

Current Implementation:
1. On successful join:
- Save NIB data to custom NVS region
- Save Security Keys
2. On boot/rejoin attempt:
- Restore NIB data from custom NVS
- Restore Security Keys from custom NVS
- Calling bdb_setNodeIsOnANetwork() - Tell BDB that device has network parameters so it can attempt secure rejoin
- Clear startup options to allow network state restoration on next boot
- Writing NIB via osal_nv_write
- Restart the device

Problem:
NLME_RestoreFromNV() consistently returns FALSE. Since this is a precompiled library function, I cannot debug why it's failing.

Questions:
- What conditions cause NLME_RestoreFromNV() to return false?
- Is there a specific initialization sequence or NV items that must be set before calling this function?
- Should I be using a different API for restoring network state after a leave event?
- Does the network key need to be handled separately from the NIB structure?

What I've Tried:
- Verified NV write operations succeed
- Verified NIB data integrity with CRC checks before restore
- Called restore at different points in initialization sequence

Any guidance on either issue would be greatly appreciated. For Issue 1, even general debugging strategies would help. For Issue 2, understanding the restore API requirements would unblock my prototype.

Thank you!

RE: CC2652R7: ZED Unexpected Network Leave + NLME_RestoreFromNV() Returns False

Ryan Brown1 — Wed, 15 Apr 2026 14:16:04 GMT

Hello Rafal,

Here are some similar E2E threads although I do not believe they are identical to your observations.

CC2652R7: ZED Randomly leaves network
CC2652P: why ZC send a Leave request to ZED automatically?

Issue 1: You have a firm grasp on mechanisms which could be causing a network Leave without rejoin. Are you using a SimpleLink F2 device for your ZC/ZR parent as well? If this source code is not from TI then it becomes even more difficult to determine what could be causing the Leave without having a sniffer log. You could try to force the issue by leaving the ZED off for a few hours, or the same for turning off all available network parents while leaving the ZED on. You can also debug the ZED code by placing breakpoints at each call to NLME_LeaveReq and bdb_setFN as based on issue 2 it appears that a factory reset is being performed. Does your ZED rejoin as expected when it is simply reset, and how many messages does it send on average over time? Can devices fail in the field regardless of how long they have been active, or are older devices more susceptible?

Issue 2: Since NLME_RestoreFromNV returns FALSE we have reason to believe that the ZED is initiating a factory reset. This is most commonly performed through the bdb_setFN API. This would erase all existing NV flash memory and start the device in a new network state configuration (ZDApp_RestoreNetworkState). So your idea of storing NVS would be ineffective if using the Zigbee application NV memory section which is reset on a factory reset (zgReadStartupOptions). ZEDs should be perfectly capable of restoring network settings on a reset, the exception being if they have been instructed to start into a new state. You could modify the application to not allow a factory reset of the NV memory and force a rejoin, however this could be rejected by the parent if it sent a Leave without rejoin command. What you've described sounds a bit like Zigbee Cloning which you can read more about in this App Note. If you don't want your custom NV to be affected by the Z-Stack state machine then you would need to add a different NV section to SysConfig which is directly controlled by the NVS TI Driver. This would need to be accounted for in your command linker file.

Regards,
Ryan

RE: CC2652P: Which file can change TX_POWER, Bootloader Backdoor DIO, and LF Clock Source

Kimi Hu — Tue, 14 Apr 2026 01:34:17 GMT

Hi Ryan,

Thank you. It works

CC2652P: Which file can change TX_POWER, Bootloader Backdoor DIO, and LF Clock Source

Kimi Hu — Fri, 10 Apr 2026 10:18:15 GMT

Part 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 & Trigger Level of Bootloader Backdoor
LF Clock Source

RE: CC2652P: Which file can change TX_POWER, Bootloader Backdoor DIO, and LF Clock Source

Ryan Brown1 — Mon, 13 Apr 2026 11:39:04 GMT

Did you add the CLI arguments as instructed in the GitHub document I linked? This would explain the board and device missing arguments.

// @cliArgs --product <path to SDK>/.metadata/product.json --board /ti/boards/CC1352P_2_LAUNCHXL --rtos freertos

Your SDK path could look like "/home/kimi/ot-ti/third_party/ti_simplelink_sdk/repo_cc13xx_cc26xx/.metadata/product.json"

Regards,
Ryan

RE: CC2652P: Which file can change TX_POWER, Bootloader Backdoor DIO, and LF Clock Source

Kimi Hu — Mon, 13 Apr 2026 01:48:58 GMT

Hi Ryan,

I download and use the sysconfig(linux version) tool. But I cannot open the sysconfig file. Pleas tell me how to fix it, thank you.

I try to open it by terminal but I get another error

RE: CC2652P: Which file can change TX_POWER, Bootloader Backdoor DIO, and LF Clock Source

Ryan Brown1 — Fri, 10 Apr 2026 13:11:24 GMT

Hi Kimi,

These are achieved through modification of the openthread.syscfg file, preferably by using the standalone SysConfig tool.

Custom -> IEEE -> TX power
Device Configuration -> Enable Bootloader / Backdoor
Device Configuration -> LF Clock Source

Regards,
Ryan

RE: CC2745R10-Q1: Is there a way to use CAN FD on CC2745 without FreeRTOS?

Christin Lee — Thu, 09 Apr 2026 13:12:29 GMT

Please do not post the same question on multiple forums. I will close this one and respond on Bluetooth LE forum

CC2745R10-Q1: Is there a way to use CAN FD on CC2745 without FreeRTOS?

zeng wang — Mon, 30 Mar 2026 02:04:45 GMT

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

CC2652P: CC2652P (Sonoff Zigbee 3.0 Dongle Plus) sends NWK key but ignores APS Request Key (TCLK) and Secure Rejoin Request

Elisavet Papadopoulou — Tue, 07 Apr 2026 17:55:49 GMT

Part Number: CC2652P

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.

RE: CC2652P: CC2652P (Sonoff Zigbee 3.0 Dongle Plus) sends NWK key but ignores APS Request Key (TCLK) and Secure Rejoin Request

Ryan Brown1 — Wed, 08 Apr 2026 13:39:09 GMT

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

CC2755P10: CC2755 - Need help with power rails.

Narashiman P — Wed, 08 Apr 2026 03:24:54 GMT

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

RE: CC2755P10: CC2755 - Need help with power rails.

RGW — Wed, 08 Apr 2026 10:58:49 GMT

Hi,

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.

CC2674P10: Enabling 20dBm for ZNP on CC2674P10 RGZ

Shuyang Zhong — Thu, 02 Apr 2026 07:21:57 GMT

Part Number: CC2674P10

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,

Shuyang

RE: CC2674P10: Enabling 20dBm for ZNP on CC2674P10 RGZ

Shuyang Zhong — Wed, 08 Apr 2026 05:15:13 GMT

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

Shuyang

RE: CC2674P10: Enabling 20dBm for ZNP on CC2674P10 RGZ

Ryan Brown1 — Tue, 07 Apr 2026 19:00:29 GMT

Based 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,
Ryan

RE: CC2674P10: Enabling 20dBm for ZNP on CC2674P10 RGZ

Ryan Brown1 — Mon, 06 Apr 2026 14:14:32 GMT

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

RE: CC2674P10: Enabling 20dBm for ZNP on CC2674P10 RGZ

Shuyang Zhong — Fri, 03 Apr 2026 08:26:12 GMT

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

Shuyang

RE: CC2674P10: Enabling 20dBm for ZNP on CC2674P10 RGZ

Ryan Brown1 — Thu, 02 Apr 2026 14:07:23 GMT

Hi Shuyang,

I'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, &responseWaitTime);

    uint16_t transactionPersistenceTime = 500;
    ZMacSetReq(MAC_TRANSACTION_PERSISTENCE_TIME, (byte *)&transactionPersistenceTime);

    uint8_t macFrameRetries = ZMAC_MAX_FRAME_RETRIES;
    ZMacSetReq(MAC_MAX_FRAME_RETRIES, &macFrameRetries);

    ZMacSetTransmitPower( (ZMacTransmitPower_t)20 ); //CHANGED FROM TX_POWER
}

You could also use the SYS_SET_TX_POWER MT API during runtime.

Regards,
Ryan

RE: CC2755P10: CC2755P10 / CC2745R10 — Output power drops and harmonics increase above a certain power threshold

desouza — Tue, 31 Mar 2026 15:11:27 GMT

Hi,

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'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.zip

CC2755P10: CC2755P10 / CC2745R10 — Output power drops and harmonics increase above a certain power threshold

Tiago Lone — Fri, 27 Mar 2026 15:31:53 GMT

Part Number: CC2755P10

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 Regards

RE: CC2755P10: CC2755P10 / CC2745R10 — Output power drops and harmonics increase above a certain power threshold

Tiago Lone — Mon, 30 Mar 2026 15:11:03 GMT

We 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 "tragic".

And all devices are marked with the letter "F" on its package. See photos below:

RE: CC2755P10: CC2755P10 / CC2745R10 — Output power drops and harmonics increase above a certain power threshold

desouza — Mon, 30 Mar 2026 13:22:46 GMT

Hi,

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 "F" on its package (check the device'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,

Rafael

RE: CC2755P10: CC2755P10 / CC2745R10 — Output power drops and harmonics increase above a certain power threshold

Tiago Lone — Fri, 27 Mar 2026 21:01:59 GMT

Thank you for the detailed response and the attached RF path information for the CC2755P10.

To confirm: all our measurements are conducted, using a Rohde & 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.

RE: CC2755P10: CC2755P10 / CC2745R10 — Output power drops and harmonics increase above a certain power threshold

desouza — Fri, 27 Mar 2026 19:29:25 GMT

Hi,

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 ±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.pdf