Bluetooth forum - Recent Threads

RE: CC2642R-Q1: CC2642-Q1 with TCAN4550 SPI_CLK rise time / fall time exceeded

xuanfeng fu — Sat, 10 Oct 2026 08:04:07 GMT

Hi Christian，

Based on your suggestion, our software colleagues have reconfigured the drive capability and slew rate of SPI_CLK separately. Oscilloscope measurements show that both have achieved desired results, and increasing the drive capability of SPI_CLK meets the rise/fall time specification requirements.

Thank you！

CC2642R-Q1: CC2642-Q1 with TCAN4550 SPI_CLK rise time / fall time exceeded

xuanfeng fu — Tue, 29 Sep 2026 08:20:21 GMT

Part Number: CC2642R-Q1

CC2642-Q1 communicates with TCAN4550 via SPI. Upon testing SPI_CLK, it was found that both the rise and fall times exceeded the maximum of 10ns specified in the specification. Despite enhancing the SPI CLK drive capability in CC2642, there was no improvement; configuring the option to Reduce Slew Rate also yielded no change. How should this be optimized?

CC2745R10-Q1: How to Use “HCI_EXT_ModemTestRxCmd”

Yasukane Yamanaka — Wed, 07 Oct 2026 10:52:59 GMT

Part Number: CC2745R10-Q1

I’m wondering if it’s possible to retrieve the RSSI for the channel specified as an argument using the “HCI_EXT_ModemTestRxCmd” command.

Therefore, I would like to know how to use this command.

(1) Does simply issuing this command enable a receive test on the specified channel?

(2) When using this command, does the transmitting side need to issue the “HCI_EXT_ModemTestTxCmd” command?

(3) Is it possible to incorporate this command into the user application’s operations, such as connection events or periodic execution by the user application?

Best regards,

RE: CC2745R10-Q1: How to Use “HCI_EXT_ModemTestRxCmd”

Maxim Altshul — Fri, 09 Oct 2026 20:28:14 GMT

1. PTM can help you with issuing the command but calling HCI_EXT_EndModemTestCmd will reset the LL, essentially dropping all connections

2. You can search Adaptivity FHSS using DAA (Detect and Avoid) in the TI user guide to see if it helps.

CC2340R5-Q1: Compiler Settings for SDK .a Libraries

hrkunied — Fri, 09 Oct 2026 03:10:06 GMT

Part Number: CC2340R5-Q1

Hello TI Team,

I am using IAR Embedded Workbench as my development environment.

I would like to align the compiler settings used for our application with those used to build the .a libraries included in the SDK.

Could you please provide the following information?

- The compiler version used to build the SDK libraries (.a files)
- The optimization settings used when building the SDK libraries

This information will help us ensure compatibility and perform a fair comparison of code size and performance.

Thank you for your assistance.

Best regards,
hrkunied.

RE: CC2340R5-Q1: Compiler Settings for SDK .a Libraries

Christian Heimvik — Fri, 09 Oct 2026 08:34:28 GMT

Hi hrkunied

Which SDK are you using? Assuming it's 9.14 as per your previous questions, these are the compiler settings we use:

Compiler Version:
IAR Embedded Workbench 9.60.3 (IAR ANSI C/C++ Compiler V9.60.3.422/LNX for ARM BX)

Optimization Settings:
-Ohz — High optimization level (-Oh) with size optimization (-z)

IAR Project Settings to Match SDK Library Build:
- CCOptLevel = 3 (High optimization)
- CCOptStrategy = 0 (Size optimization)

Best regards,
Christian Heimvik

CC2340R5-Q1: Time Until Wake-up Signal Reception Becomes Valid After Entering Shutdown State

hrkunied — Thu, 01 Oct 2026 08:45:12 GMT

Part Number: CC2340R5-Q1

Hello, Expert Team,

I am using SDK 9.14.

I have a question regarding the behavior of the Power_shutdown() API in my application.

When a wake-up signal (a Low pulse) is applied immediately after calling the shutdown transition API, Power_shutdown(), the device does not wake up. For reference, the wake-up source is configured for Low-edge detection, and I have already confirmed that the device can normally wake up from the Shutdown state when the wake-up signal is applied under normal conditions.

Could you please tell me how long it takes after executing Power_shutdown() before the device is ready to receive and respond to the next wake-up signal?

This could be a significant risk for the application I am developing, so I would like to understand the timing requirement in detail.

I have attached a timing diagram from my evaluation below.

Thank you for your support and assistance.

Best regards,

hrkunied.

RE: CC2340R5-Q1: Time Until Wake-up Signal Reception Becomes Valid After Entering Shutdown State

Christian Heimvik — Fri, 09 Oct 2026 08:10:58 GMT

Hello hrkunied,

Thank you for the update and for confirming that the mitigation is effective on your end. We will continue analyze the behavior you describe here and reach out if we have any findings or updates.

Thank you for your collaboration, and feel free to start a new thread if any other questions arise.

Best regards,
Christian

RE: CC2642R-Q1: CC2642-Q1 with TCAN4550 SPI_CLK rise time / fall time exceeded

Christian Heimvik — Fri, 09 Oct 2026 08:08:02 GMT

Hi Xuanfeng,

Thank you for the details. As previously noted, if adjusting the drive strength and slew rate yields zero change on the oscilloscope, it typically indicates that there is an external hardware limitation masking the adjustments. However, in any case, we suggest you do either (or all) of the following:

Slew Rate Definition Realignment: In the CC2642R architecture, configuring the option to "Reduce Slew Rate" actually makes the rise/fall time slower (pre-driver throttling). Please ensure that Reduce Slew Rate is completely disabled (set to 0/False) to achieve the fastest possible edges. You can find this in the Technical Reference Manual page 1134; (CC13x2, CC26x2 SimpleLink Wireless MCU Technical Reference Manual (Rev. G)).
Explicit High-Drive Configuration: Ensure the SPI_CLK DIO pin is explicitly set to Maximum Strength (IOC_STRENGTH_MAX) via DriverLib right after SPI_open(). Sometimes the default peripheral initialization overrides global pin settings.
Hardware & Probe Validation:
- Do you have a series termination resistor on the SPI_CLK line? If so, try lowering its resistance or bypassing it temporarily.
- Try measuring using a low-capacitance active probe or a short ground spring probe attachment right at the TCAN4550 pin to ensure the oscilloscope probe capacitance isn't artificially slowing down the measurement.

Please let me know if disabling the slew rate reduction alters the scope waveform!

Best regards,
Christian

RE: CC2340R5: CC2340R5 (Zephyr, CONFIG_PM=y): device stays in STANDBY forever while creating a periodic advertising sync — SysTimer interrupt seems to stop

Faizan Habib — Fri, 09 Oct 2026 06:50:09 GMT

Hi Eiichiro,

Thank you for providing the results and sharing the firmware and logs. I will have a look into it and get back to you.

Best Regards,
Faizan

CC2340R5: CC2340R5 (Zephyr, CONFIG_PM=y): device stays in STANDBY forever while creating a periodic advertising sync — SysTimer interrupt seems to stop

Eiichiro Taguchi — Tue, 06 Oct 2026 09:09:24 GMT

Part Number: CC2340R5

Hello,

We are developing a BLE Periodic Advertising receiver (synchronized receiver) on CC2340R5 with the TI Zephyr fork, and we see the device occasionally enter STANDBY and never wake up again. It looks like a power management / system timer issue rather than a Bluetooth host issue, so we would like to ask whether this is known, and whether there is a fix or a recommended workaround.

Environment

Board: LP-EM-CC2340R5 (+ LP-XDS110), 2 boards (one advertiser, one receiver)
SDK: TI Zephyr fork v3.7.0-ti-1.00.01_ga (simplelink-hal_ti ab1817da) and v3.7.0-ti-9.20.00_ea (simplelink-hal_ti d52be897, "218d961-ti-9.20.00") — same behavior
Toolchain: Zephyr SDK 0.16.8
Receiver app: our own small test app (Zephyr host API), CONFIG_PM=y (default)
Advertiser: CC2340R5 with the same SDK, Periodic Advertising interval 20 ms, 244-byte AUX_SYNC_IND, Extended Advertising (discovery) interval 507.5 ms

What the receiver does

To make the issue frequent, the receiver repeats this loop (about 650–770 sync creations per hour):

bt_le_scan_start() (passive, 30/60 ms window/interval, no duplicate filtering)
on the extended advertising report with SyncInfo → bt_le_per_adv_sync_create()
when synced → receive for 3 s → bt_le_per_adv_sync_delete() → back to 1 (if not synced in 15 s → delete the pending sync and go back to 1)

A k_timer prints a heartbeat from the timer callback every 10 s, and the host prints a timestamped log line for every step.

Symptom

After some minutes to tens of minutes, the log stops right after "found" (step 2, while the sync is being created).
The 10-second heartbeat from the k_timer callback also stops, so the system timer interrupt is no longer delivered (not just the main thread being blocked).
Attaching the debugger without halting (pyOCD connect_mode=attach): all APs return WAIT, i.e. the CPU is in STANDBY.
It does not wake up by itself: we waited 78 minutes (longer than one SysTimer wrap, ~71.6 min) and it was still asleep. Restarting the advertiser does not wake it either. Only reset recovers.

It depends on power management

Same receiver app, same loop, same advertiser:

Receiver	Run time	Syncs established	Stalls
`CONFIG_PM=y`	~35 min	~315	2 (after 2 min and 9 min)
`CONFIG_PM=n`	120 min	1,285	0

On other days we saw 3 stalls in 4 runs (each within 2–2.5 minutes of starting), and 5 stalls in 24 minutes. The frequency varies a lot from day to day: from roughly 1 stall per 30–300 sync creations down to 2 stalls in 3 hours (2,323 sync creations, none in the first 2 hours).

CONFIG_PM=n avoids it, but the receiver is battery powered, so we would like to keep STANDBY.

Additional observations

When a thread wakes up every 1 s (we tried feeding the watchdog every 1 s), the stall did not happen (303 syncs in 24 min, 0 stalls). With wake-ups only every 5–10 s, it stalls. So it seems to happen when the device enters a long STANDBY while the radio is scheduling the sync (AUX_SCAN / sync scan).
With the hardware watchdog enabled (wdt_lpf3, 12 s), the device was reset and recovered in all real stalls, so the watchdog keeps running in this state. (16 of 16 so far, including the runs below.)
We looked at soc/ti/simplelink/cc23x0/power.c (pm_cc23x0_enter_standby), drivers/timer/lpf3_clockp_timer.c and modules/hal/ti/simplelink_lpf3/kernel/zephyr/dpl/ClockP_zephyr.c, but could not find the cause. Our guess is that the next wake-up (SysTimer / RTC compare) is lost or set in the past when STANDBY is entered while the radio driver (RCL) changes its schedule.

Newer SDK

We also tested v3.7.0-ti-1.00.01_ga (simplelink-hal_ti ab1817da) with the same app, the same loop and the same advertiser, back to back with the EA build on the same evening (to reduce the day-to-day variation):

Receiver SDK	Run time	Syncs established	Stalls	Recovered by watchdog
`v3.7.0-ti-1.00.01_ga`	120 min	1,540	2 (after 15.6 and 18.2 min)	2 / 2
`v3.7.0-ti-9.20.00_ea` (reflashed, right after the GA run)	120 min	1,531	5	5 / 5

So the stall still happens with 1.00.01 GA. The power.c / lpf3_clockp_timer.c / ClockP_zephyr.c sources are unchanged between 9.20.00_ea and 1.00.01_ga (only the BLE controller library and RCL changed), which is consistent with this. The difference in count (2 vs 5) is within the day-to-day variation we have seen.

Second issue: scan start keeps failing with -EACCES after deleting a pending sync

Once in our tests (in a 24-minute run of the loop above), after bt_le_per_adv_sync_delete() on a pending (not yet established) sync, bt_le_scan_start() returned -EACCES (HCI Command Disallowed) continuously for 11 minutes (retried every 1 s), until we reset the device. The system itself was alive (heartbeat running). It looks like the controller still considered the "create sync" as running after the cancel. Usually bt_le_scan_start() right after the delete fails with -EACCES only once or twice and then succeeds after a short wait.

Questions

Is the STANDBY stall known? It still happens with 1.00.01 GA. We noticed that in v4.4.0-ti-10.10.00 (the CC35xx release) the cc23x0 power.c and system timer driver are replaced by the upstream-style implementation (cc23x0_systim_timer.c / cc23x0_rtc_timer.c), but that release does not include BLE for CC2340R5. Is a fix planned for the v3.7.0-ti-1.00 line, or is there a plan for a CC2340R5 BLE release based on that newer implementation?
Is there a recommended workaround other than CONFIG_PM=n or a watchdog (e.g. a maximum STANDBY duration setting, or a constraint to set while a sync is being created)?
For the second issue: what is the correct way to cancel a pending periodic advertising sync so that scanning can be restarted reliably (should the host wait for a specific event after HCI LE Periodic Advertising Create Sync Cancel)?

We can provide the test app, build configuration and logs.

Best regards, Eiichiro Taguchi

CC2640: Problem with notification messages

Michael McCully — Thu, 17 Sep 2026 09:47:45 GMT

Part Number: CC2640

Hello,

I have a couple of TI BLE devices with a specific BLE profile, and both devices have been running for several years. One device is based on the CC2541, and the other on the CC2640. Both collect data and send it in BLE notification messages to a PC. The PC receives this data using a TI CC2540 BLE USB dongle, always with no problems.

Recently we also started using Android devices to receive data. The problem is this: the Androids receive all of the notification messages from the CC2541 device but not from the CC2640. Using a BLE sniffer, I found that the CC2541 always supplies the correct BLE characteristic handle number in the notification message when it is sent, but the CC2640 does not. What I mean is, the correct handle number for the notification message is 0x0012, and the CC2541 device sends 0x0012 with every notification. The CC2640, on the other hand, sends a handle number of 0x0000 first, then 0x0012, then 0x0024, then 0x0036, etc. I am using TI's GATT_Notification() function to send my data buffer to the CC2640 BLE stack, so it looks to me like the CC2640 BLE stack is incrementing/changing the characteristic handle value by 0x0012 instead of setting it to 0x0012.

Maybe I'm wrong in my assumption. Maybe I've overlooked a function call parameter when I offload the data to the BLE stack. In any case, I'm at a loss as to why the CC2640 doesn't send the right handle number (and the CC2541 does) with every notification message.

For the record, the CC2541 code was built using IAR Workbench. The CC2640 program and stack were built with CCS 6.2 and TI's BLE stack 2.2.1.18.

Anybody have any ideas on why the handle number isn't set to 0x0012 (or is incremented by 0x0012) with the CC2640 GATT_Notification() call?

Thanks,
Mike

RE: CC2640: Problem with notification messages

Michael McCully — Fri, 09 Oct 2026 06:11:32 GMT

Hey Tarek,

Have you come up with anything in the BLE sniffer log?

We had a CC2650 LaunchXL board to use to try out the out-of-box simple_peripheral hex file, but there was a hardware problem with our board. We're in the process of getting another one, and as soon as we do, I'll let you know what I find out.

Best Regards,

Mike

RE: CC2642R-Q1: CC2642-Q1 with TCAN4550 SPI_CLK rise time / fall time exceeded

xuanfeng fu — Fri, 09 Oct 2026 00:57:45 GMT

Hi Christian，

We adjusted the drive capability and slew rate, but the actual measured rise/fail time did not change at all, which is quite strange. Could you please help analyze it?

RE: CC2340R5-Q1: Time Until Wake-up Signal Reception Becomes Valid After Entering Shutdown State

hrkunied — Thu, 08 Oct 2026 23:31:47 GMT

Hello Christian,

Thank you for your response.

We have already confirmed that our mitigation is effective by monitoring multiple wake-up edges and checking the return status of Power_shutdown().

Thank you for your suggestion.

I will close this thread. However, the fact remains that there are cases where the device fails to wake up, so I would greatly appreciate it if you could continue investigating the issue whenever time permits.

Finally, I would like to sincerely thank you for answering my many questions throughout this discussion. Your support has been extremely helpful.

Thank you again for all your assistance.

Best regards,
hrkunied.

RE: CC2755P20: External LNA for CC2755P20

desouza — Thu, 08 Oct 2026 15:04:10 GMT

Hi,

Unfortunately we don't have a ready design using an external LNA for the CC2755P20 device at this time.

Regards,

Rafael

CC2755P20: External LNA for CC2755P20

Arthur Shidlovskiy — Wed, 07 Oct 2026 15:20:39 GMT

Part Number: CC2755P20

Hello everyone. We're developing a system for measuring the distance between two bracelets worn by a person. The goal is to determine the distance with an accuracy of +/- 2-3 m at a range of 150 m NLOS. We're using a two-antenna design on each device. The antennas are Abracon Pro-OB 440, PIFA, stamped. The board size is 70 x 40 mm. If anyone can suggest more efficient antennas, I'd be grateful. My question is, can an external LNA be used to increase the receiver's sensitivity? Is there a signal that can be used to switch the antenna between receive and transmit? Thanks in advance for your reply.

RE: CC2744R7-Q1: CC2745R10-Q1 Channel Sounding – Antenna Configuration and Accuracy in SDK 9.20.01.21

Isaac Larson — Thu, 08 Oct 2026 14:23:36 GMT

Hello Vaibhav,

Ok, so you configuration should be as follows for the .aci and .preferredPeerAntenna procedure parameters:

.aci = 0,

.preferredPeerAntenna = 0b0001;

This will ensure 1x1 antenna configuration. Additionally, your embedded firmware should also reflect this configuration (car_node and key_node).

1x1 antenna configuration is the most susceptible to ranging distance error. This is due to a couple of reasons:

1. Multi-path reflections. The CS tones will reflect off of reflective surfaces within your environment, yielding to primarily an increase in distance results. Since the reflection is a traveling 1. to the reflection spot, 2. from reflection spot to reflector/initiator, the phase for that tone will be a combination of the two paths. Compared to the direct path which is less than the combination of those two paths.

2. Less data collection. This goes hand in hand with multi-path reflections. With only one antenna path, if your antenna path is reflected, there are no other antenna paths to compensate for the abnormal antenna path. Thus, the end data reflects only the data found on the one antenna path which is tainted with reflection phase data.

I have talked to our marketing team. Please reach out to your FAE or to Achyut Ray. He will assist in obtaining CS EVMs for testing.

Thanks,
Isaac

CC2744R7-Q1: CC2745R10-Q1 Channel Sounding – Antenna Configuration and Accuracy in SDK 9.20.01.21

Vaibhav Patil — Tue, 06 Oct 2026 14:47:05 GMT

Part Number: CC2744R7-Q1

Hi TI Team,

I am working with the CC2745R10-Q1 for Bluetooth Channel Sounding and would like some clarification regarding the relationship between the antenna configuration and ranging accuracy.

I am currently using SimpleLink Low Power F3 SDK 9.20.01.21 and observing relatively low distance accuracy with my current Channel Sounding configuration.

I would like to understand:

What antenna configuration does TI recommend for automotive PEPS/proximity ranging applications? In particular, is there a recommended number of antennas for achieving better ranging accuracy?
Is the ranging accuracy I am observing expected with my current antenna configuration, or are there specific Channel Sounding/antenna configurations recommended to improve accuracy on the CC2745R10-Q1?

Any guidance on the recommended hardware and Channel Sounding configuration for an automotive PEPS/Close proximity Ranging use case would be helpful.

Below are my configs at initiator side:

CS_setProcedureParamsCmdParams_t csSetProcedureParams = {
    .configID = 0,
    .maxProcedureDur = 0xFFFF,
    .minProcedureInterval = 0,
    .maxProcedureInterval = 0,
    .maxProcedureCount = 1,
    .minSubEventLen = 0xD6D8,
    .maxSubEventLen = 0xD6D8,
    .aci = 7,
    .phy = 1,
    .txPwrDelta = CS_TX_PWR_DELTA_NO_RECOMMENDATION,
    .preferredPeerAntenna = 0b0011,
    .snrCtrlI = 0xFF,
    .snrCtrlR = 0xFF,
    .enable = 0,
};

CS_createConfigCmdParams_t csConfigParams = {
    .configID = 0,
    .createContext = 1,
    .mainMode = 2,
    .subMode = 0xFF,
    .mainModeMinSteps = 0,
    .mainModeMaxSteps = 0,
    .mainModeRepetition = 3,
    .modeZeroSteps = 3,
    .role = 0,
    .rttType = 0,
    .csSyncPhy = 1,
    .channelMap = {0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF},
    .chMRepetition = 1,
    .chSel = 0,
    .ch3cShape = 0,
    .ch3CJump = 0,
};

Regards,
Vaibhav

RE: CC2755P20: External LNA for CC2755P20

Arthur Shidlovskiy — Thu, 08 Oct 2026 13:44:15 GMT

This is very cool. Is there a ready-made reference design for using an LNA in the 2.4 GHz range?

We already have a design for two antennas. I understand perfectly what we're talking about.

RE: CC2755P20: External LNA for CC2755P20

desouza — Thu, 08 Oct 2026 13:33:10 GMT

Hi,

[quote userid="432200" url="~/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1687716/cc2755p20-external-lna-for-cc2755p20"]If anyone can suggest more efficient antennas, I'd be grateful. [/quote]

According to its datasheet, the antenna you are using has quite reasonable gain already, so I don't have any remarks.

I imagine your dual antenna will be configured similarly to our channel sounding reference design, is that so? If you don't know what I am talking about, please check the page below, which contains all design information:

https://www.ti.com/tool/CC2745R10-CS-EVM

The use of an external LNA is possible and is mentioned in section 28.3.3.2 of the CC27xx20 Technical Reference Manual. As this section indicates, please use the latest Simplelink F3 SDK 9.21, which fully supports the CC2755P20 device to implement this.

Hope this helps,

Rafael

RE: CC2745R10-Q1: Facing Issue For RNG for CC2745R10 device

Jonas Brandt — Thu, 08 Oct 2026 13:25:45 GMT

This will be handled further over email.

CC2745R10-Q1: Facing Issue For RNG for CC2745R10 device

Balaji Wankhede — Tue, 22 Sep 2026 06:30:07 GMT

Part Number: CC2745R10-Q1

Hello team,

i'm trying to generate the RNG for CC2745r10 device, when i'm trying with step by step debug mode i'm getting but after random Number generate my code going into the Exception_handlerSpin().

sdk version: simplelink_lowpower_f3_sdk_9_14_02_15

CCS version: 20.4

please find the below code for RNG init:

void Generate16BytesRNG(void)

{

RNG_init();

rngHandle = RNG_open(0, NULL);

if (rngHandle == NULL)

{

UART2_write(uart, "\r\nRNG Open Failed", 17, NULL);

return;

}

/* 16 bytes = 128 bits */

result = RNG_getRandomBits(rngHandle,

randomBytes,

RNG_16_BYTES * 8U);

if (result == RNG_STATUS_SUCCESS)

{

UART2_write(uart, "\r\nRNG Success", 13, NULL);

/* Print 16 random bytes */

for (uint8_t i = 0; i < 16U; i++)

{

char buf[4];

sprintf(buf, "%02X ", randomBytes[i]);

UART2_write(uart, buf, 3, NULL);

}

else

{

UART2_write(uart, "\r\nRNG Failed", 12, NULL);

}

RNG_close(rngHandle);

}

once RNG genearte after that in my device is not reflashed.

what is the dependacy of RNG is there any setting RNG other that config in sys config.

please suggest me is there any dependacy of RNG with HSM ?

thanks & regards

Balaji W

RE: CC2651R3: Smartrf Studio Download

RGW — Thu, 08 Oct 2026 12:58:47 GMT

If the issue persists after verifying your account details and trying from your personal email then you will need to contact TI's myTI account support directly, as download access blocks related to export compliance can only be resolved by TI's order/account team — this is not something the E2E technical forums can address.:

SmartRF Studio Download Issue

The SmartRF Studio 7 download page is available on TI.com under the tool listing SMARTRF™-STUDIO. If the page is prompting you to "contact support" instead of allowing the download, this is typically caused by one of the following:

myTI Account Required — You must be logged into a valid myTI account. If you don't have one, create one at my.ti.com and then retry the download.
Export Control Restrictions — SmartRF Studio may be subject to export compliance screening. Ensure your myTI profile has complete and accurate information (name, company, country, end-use). Incomplete profiles can trigger a block that displays a "contact support" message.
Browser/Region Issues — Try clearing your browser cache, using a different browser, or disabling any VPN that might route your traffic through a restricted region.