Bluetooth forum - Recent Threads

CC2650MODA: Quality & Packaging / Regulatory & Compliance

Dobromir Todorov — Fri, 24 Jul 2026 12:25:22 GMT

Part Number: CC2650MODA
Other Parts Discussed in Thread: CC3220MODA

Requesting the full EN 60950-1 (or EN 62368-1) Safety Test Report / Protocol Data for CC2650MODA / CC3220MODA for end-product CE mark technical file compilation.

Thank you in advance

CC26XX-RESOURCES: Upgrade of CC26XX SDK

Josef Luttenbacher — Fri, 24 Jul 2026 11:51:38 GMT

Part Number: CC26XX-RESOURCES
Other Parts Discussed in Thread: SYSCONFIG

When trying to migrate the project to current versions of the tool chain (CCS V21.0, compiler V20.2.7.LTS, XDC tools V3.62.1.15 and SimpleLink CC13XX CC26XX SDK V8.33.0.16) I succeeded to import into the new CCS, change the compiler and the XDC toos. When switching to SDK V8.33 I first get some errors reported by SysConfig concerning the RTOS, UART, some BLE and GPIO settings, but I was able to fix these by changing the .syscfg file and then adopting some values in SysConfig, as soon as it opens. But finally when generating the project I'm stuck with the error message:

[1]js: "C:/ti/xdctools_3_62_01_15_core/packages/xdc/tools/Cmdr.xs", line 52: Error: xdc.tools.configuro: Error: Can't find the platform package 'ti.platforms.simplelink'. TI platforms are no longer shipped as part of XDCtools (C:\ti\xdctools_3_62_01_15_core). Please ensure you are either using a pre-3.30 version of XDCtools or you have added a product that includes your platform support along the path 'C:/ti/simplelink_cc13xx_cc26xx_sdk_8_33_00_16;C:/ti/xdctools_3_62_01_15_core/packages;C:/ti/simplelink_cc13xx_cc26xx_sdk_8_33_00_16/source;C:/ti/simplelink_cc13xx_cc26xx_sdk_8_33_00_16/kernel/tirtos/packages;C:/ti/simplelink_cc13xx_cc26xx_sdk_8_33_00_16/kernel/tirtos7/packages;C:\ti\xdctools_3_62_01_15_core/packages'. Check that this path names a directory containing the necessary platform support and that the platform name is properly spelled.

This seems to be caused by the fact that in contrast to SDK V4.10 the new SDK V8.33 does not contain such platform definitions. How to solve this? Is there any other location where to retrieve these platform definitions from? Any other way to migrate from SDK V4.10 to V8.33?

CC2640R2F: Request for Clarification on BLE Error Code 0x19 / GATT Error Code 6

Jayaprakash A — Fri, 24 Jul 2026 11:26:37 GMT

Part Number: CC2640R2F

Dear Support Team,

We are using the CC2640R2F module in our running project with SDK version 4.30.00.08.

During normal riding conditions, the customer has reported intermittent disconnection issues. From the mobile application logs, we observed GATT Error Code 6. To investigate further, we enabled BLE logs on the module and found HCI Error Code 0x19.

According to the TI SDK documentation, Error Code 0x19 corresponds to HCI_ERROR_CODE_UNKNOWN_LMP_PDU.

Could you please help us understand the following?

What does HCI_ERROR_CODE_UNKNOWN_LMP_PDU (0x19) indicate?
Under what conditions is this error generated?
What are the possible root causes of this error?
How can this issue be handled or mitigated in the CC2640R2F module using SDK version 4.30.00.08?

We would appreciate your support on an urgent basis, as this issue is impacting our customer's application.

Thank you, and we look forward to your prompt response.

AM625: AM62x SK-EVM: WL1837 Bluetooth on UART1 fails with "Failed to get CTS" despite correct pinmux, GPIO routing, and DT node — need WL1837 chip-enable pin reference

krushna moukthik — Fri, 24 Jul 2026 07:43:47 GMT

Part Number: AM625
Other Parts Discussed in Thread: WL1837, TCA6424,

Board: AM62x SK-EVM (TI part: AM6254ATCGHAALW)
BSP: Yocto Kirkstone 4.0.35, meta-ti-bsp/meta-ti-extras, linux-ti-staging 6.1.83

GOAL
Enable onboard WL1837 Bluetooth (HCI over UART) on main_uart1 (schematic
label: UART2), which is disabled by default in TI's k3-am625-sk.dts /
k3-am62x-sk-common.dtsi for this EVM.

WHAT I'VE VERIFIED AS CORRECT (confirmed via decompiled final DTB and
runtime debugfs/pinmux inspection, not just source review)

1. UART1 pinmux is now correctly muxed
- Added main_uart1_pins_default group with AM62X_IOPAD entries for
UART1_RXD, UART1_TXD, UART1_CTSn, UART1_RTSn
- Bound via pinctrl-names/pinctrl-0 on &main_uart1
- Confirmed in decompiled final DTB: pinctrl-0 resolves to a valid
phandle, uart-has-rtscts present, status = "okay"
- Before this fix, /sys/kernel/debug/pinctrl/.../pinmux-pins showed
ZERO pins claimed for UART1 at all (compare to main_uart0 which
showed 2 pins correctly muxed) — this was a genuine gap in the
stock SK-EVM DTS

2. UART1 signal-path GPIO fan-out is correct and active
- Board routes UART1 TX/RX/RTS/CTS through analog switches (FETs)
controlled by IO-expander (tca6424, addr 0x22) lines:
- UART1_FET_BUF_EN (line 10)
- UART1_FET_SEL (line 21)
- Added as gpio-hog nodes; confirmed in dmesg:
gpio-354 (UART1_FET_BUF_EN): hogged as output/high
gpio-365 (UART1_FET_SEL): hogged as output/high

3. Bluetooth DT child node is correctly declared
- Added under &main_uart1:
bluetooth {
compatible = "ti,wl1837-st";
max-speed = <3000000>;
};
- Matches Documentation/devicetree/bindings/net/ti,bluetooth.yaml
- hci0 is created (serdev probe succeeds), confirming the node/binding
itself is structurally correct

4. serial alias added (main_uart1 had no "serial3" alias in the SK-common
DTSI, causing omap8250 to log "failed to get alias" — fixed via
separate alias patch)

WHAT'S STILL FAILING

dmesg on every boot after all of the above:
Bluetooth: hci0: Failed to get CTS

hciconfig -a:
hci0: Type: Primary Bus: UART
BD Address: 00:00:00:00:00:00 ACL MTU: 0:0 SCO MTU: 0:0
DOWN

WHAT I'VE RULED OUT (tested directly, not assumed)

A. vio-supply / vbat-supply on the bluetooth DT node
- ti,bluetooth.yaml documents these as valid properties
- BUT: grep of drivers/bluetooth/hci_ll.c in this kernel tree shows
ZERO references to these properties anywhere in the driver code —
confirmed the driver does not request or enable them. Adding them
to DT was schema-valid but functionally inert.

B. Forcing wlan_lten / wlan_en (the level-translator supply regulators,
gpio-controlled via IO-expander line 11 "WL_LT_EN") to
regulator-always-on / regulator-boot-on
- This DID successfully enable the regulators (confirmed via
/sys/kernel/debug/regulator/regulator_summary: use count went
from 0 to 1-2)
- BUT: Bluetooth still fails with the identical "Failed to get CTS"
error
- AND: this change broke WiFi entirely — wl18xx/wlcore modules
stopped probing, no wlan0 interface, no mmc2 SDIO card enumeration
in dmesg. Reverted this change; WiFi bring-up recovered immediately
on next boot, confirming this regulator change was the specific
cause. This is now excluded as a fix.

C. Confirmed via drivers/bluetooth/hci_ll.c source: the driver DOES
implement enable-gpios handling (devm_gpiod_get_optional(dev,
"enable", ...) at line 700, with gpiod_set_value_cansleep() toggling
it low then high as part of the LL wakeup sequence at lines 626-628).
This appears to be the real, implemented chip-enable mechanism — but
I don't have a confirmed correct GPIO pin to point it at. I tried
IO-expander line 19 ("MCASP1_BUF_BT_EN") based on its name, but
gpioinfo showed this line was never actually claimed/used by any
node on the schematic-derived DTS, suggesting it's not the real
WL1837 enable pin either. WL_LT_EN (line 11) is already claimed by
the wlan_lten regulator and controls the level-translator buffer
supply, not — as far as I can tell — the WL1837 module's own
chip-enable/reset pin.

QUESTION FOR TI

1. What is the correct GPIO (or other mechanism) that drives the WL1837
module's own chip-enable/reset pin on the AM625 SK-EVM, as distinct
from WL_LT_EN (level-translator buffer supply) and UART1_FET_BUF_EN/
UART1_FET_SEL (signal routing switches)?

2. Is there a reference DTS anywhere in TI's tree (any AM62x variant
board) showing WL1837/WL18xx Bluetooth correctly enabled over a
shared UART, that I could use as a working example? I was unable to
find one in meta-ti-bsp or the mainline kernel tree for this specific
board.

3. Does the WL1837 combo chip require a specific power-up sequence/delay
between asserting WL_LT_EN (level translator) and the chip's own
enable-gpios line before UART flow-control signaling becomes valid?
If so, what is the expected timing?

I can provide my full patch set (4 patches covering pinmux, GPIO hogs,
BT node, and the reverted always-on regulator attempt) on request.
BT_issue.zip

CC2340R5: CC2340R53: BT Mesh + custom connectable GATT peripheral — service discovery hangs/disconnects (relates to "Zephyr peripheral sample not connecting" thread)

Ramprasad G — Wed, 22 Jul 2026 14:33:46 GMT

Part Number: CC2340R5

Hello,

We're building a Bluetooth Mesh application on the LP-EM-CC2340R53, and are now trying to add a secondary connectable BLE peripheral role (custom GATT service) for mobile app control, alongside mesh. We're hitting a connection/discovery issue that looks related to the one already reported in "Zephyr peripheral sample not connecting to simplelink connect app iOS" - wanted to raise our specific variant since it may help narrow down the root cause.

What we did:

Our app runs CONFIG_BT_MESH=y (PB-ADV only, relay enabled), plus a second bt_le_adv_start(BT_LE_ADV_CONN, ...) call for a custom GATT service (standard BT_GATT_SERVICE_DEFINE/BT_CONN_CB_DEFINE), intended for a mobile app to connect to independently of mesh traffic.

Initial attempt failed with bt_le_adv_start returning -12 (ENOMEM) - traced to the shared advertising-set pool (CONFIG_BT_EXT_ADV_MAX_ADV_SET defaulting to 1, already occupied by mesh's own advertising bearer). Fixed by setting CONFIG_BT_EXT_ADV_MAX_ADV_SET=2.

After that fix, advertising starts correctly (visible and connectable in nRF Connect), and the link-layer connection succeeds. But GATT service discovery then hangs - nRF Connect gets stuck on "Discovering services" and eventually disconnects. This is 100% reproducible, including with only a single board powered (no mesh peer traffic at all, just the node's own idle mesh beacon), so it isn't specific to multi-device relay load.

We noticed in ble_config_zephyr.c (part of the SDK's TI BLE module) that whenever CONFIG_BT_MESH=y, qosDefaultPriorityAdvParameter is forced to LL_QOS_HIGH_PRIORITY and llUsePreemption is enabled - meaning mesh's advertising can preempt an in-progress connection event. We experimented with raising our own connection's priority to match (via a global-variable override, since qosDefaultPriorityConnParameter has no default definition anywhere in the SDK source) - this didn't fix discovery, and instead introduced a new failure mode (disconnect reason 0x16, "Terminated by Local Host") instead of the original 0x13. We reverted this, since ll.h explicitly marks LL_EXT_SetQOSParameters/related internal APIs as "for internal stack use only."

We also tried the buffer-count workaround suggested in the linked thread (CONFIG_BT_BUF_CMD_TX_COUNT=20, CONFIG_BT_BUF_EVT_RX_COUNT=20) - no improvement, and on a later attempt discovery didn't even start. This also costs ~8KB RAM (79% to 92% used on this 64KB part), so we reverted it.

Our questions:

Is this the same underlying issue as the "Zephyr peripheral sample not connecting" thread, or a distinct one specific to running BT Mesh concurrently with a connectable peripheral role?

Is there a supported, documented way to adjust connection-vs-advertising radio priority/preemption behavior when CONFIG_BT_MESH=y, short of the internal-only LL_EXT_Set* APIs?

TI's Bluetooth Mesh Software Product Brief (SWRA732) documents a validated "concurrent Bluetooth Mesh + Bluetooth LE peripheral" reference example (simple_mesh_node) on the CC13x2/CC26x2 native BLE5-Stack - is equivalent coexistence support planned/expected for the CC23xx Zephyr downstream, and if so, in which upcoming release?

Is there a recommended workaround in the meantime, or should we treat mesh + connectable-peripheral coexistence as not-yet-supported on CC2340R53 until a fix lands?

Happy to share our prj.conf/logs/sniffer captures if useful.

Thanks,
Ramprasad

CC2755P10: CC2755P10 custom board RX sensitivity measurement using CMP180 instrument

Mantosh Sharma — Wed, 22 Jul 2026 09:57:22 GMT

Part Number: CC2755P10

Hello,

We have designed a custom board based on the CC2755P10 BLE device and would like to measure its RX sensitivity.

Test Setup:

Custom CC2755P10 board
XDS110 Debug Probe
Rohde & Schwarz CMP180
RF shielded chamber

Problem Description:

We are using SmartRF Studio 8 for TX and RX measurements. While we are able to measure the TX power successfully, we are not receiving any packets during RX sensitivity testing—the Packet RX counter remains zero.

We request your guidance on:

How to properly measure RX sensitivity for the custom BLE board
Possible reasons for not receiving packets in RX mode
The correct configuration required between SmartRF Studio and CMP180

Additionally, we would like to understand how to perform TX and RX measurements without using the debugger (XDS110).

Below are some snaps

CC2745R10-Q1: Guidance on Adding OAD Support to Channel Sounding car_node and key_node Examples

Vaibhav Patil — Wed, 22 Jul 2026 06:29:03 GMT

Part Number: CC2745R10-Q1

Subject: Guidance on Adding OAD Support to Channel Sounding car_node and key_node Examples

Hi Forum,

I am working with the Channel Sounding (car_node and key_node) example projects provided in the SDK. I noticed that these example projects are non-OAD based.

I would like to add Over-the-Air Download (OAD) support to these projects so that firmware updates can be performed over BLE.

Could you please provide guidance on the recommended approach for integrating OAD into these examples? Specifically, I would like to know:

Whether OAD is officially supported with the Channel Sounding examples.
Which OAD example should be used as the reference or base project.
The key modifications required to integrate the OAD profile and bootloader while preserving the existing Channel Sounding functionality.
Whether there are any known limitations or recommended practices for combining OAD and Channel Sounding.

Any documentation, application notes, or reference implementations would be greatly appreciated.

Regards,
Vaibhav

AM625: AM62x SK-EVM: WL1837 Bluetooth on UART1 (main_uart1) fails to bind — omap8250 "failed to get alias"

krushna moukthik — Tue, 21 Jul 2026 10:41:22 GMT

Part Number: AM625
Other Parts Discussed in Thread: WL1837, SK-AM62

Board: AM62x SK-EVM (AM6254ATCGHAALW), custom Yocto (Kirkstone/4.0.35) build using meta-ti-bsp, linux-ti-staging 6.1.83.

Goal: Enable onboard WL1837 Bluetooth (HCI over UART) on main_uart1 (schematic label UART2), which is disabled by default in TI's k3-am625-sk.dts / k3-am62x-sk-common.dtsi.

What I've done:
- Added a Bluetooth child node under main_uart1 (serial@2810000) with compatible = "ti,wl1837-st" and max-speed = <3000000>, matching Documentation/devicetree/bindings/net/ti,bluetooth.yaml
- Forced main_uart1 status = "okay" with uart-has-rtscts
- Added GPIO hogs for UART1_FET_BUF_EN and UART1_FET_SEL (IO expander lines 10 and 21) to route the UART path, per schematic
- Installed bt-fw, uim-sysfs, wlconf, and TI BT init firmware (.bts files) in the rootfs
- Masked serial-getty@ttyS3 to free the UART
- Set hci_uart to autoload via modules-load.d

Current status: DTB confirms main_uart1 status = "okay", Bluetooth child node present with correct compatible string, no UART getty contention, and correct firmware files in /lib/firmware/ti-connectivity. However:

dmesg shows: "omap8250 2810000.serial: failed to get alias"

/proc/device-tree/aliases only exposes serial0/serial1/serial2 — no alias for main_uart1 (which should be serial3).

Because of this, hci_uart never binds a serdev instance to the UART, hciconfig -a returns no hci0, and rfkill only shows the WLAN radio, not Bluetooth.

Question:
1. Why does TI's k3-am62x-sk-common.dtsi aliases node not include main_uart1, unlike main_uart0-2?
2. Is adding "serial3 = &main_uart1;" to the aliases node in k3-am62x-sk-common.dtsi the correct/supported way to fix this, or is there a different recommended path (e.g., via chosen node, u-boot alias passthrough, or a different serdev binding) for enabling WL1837 BT on this specific EVM?
3. Is there a reference DTS/example anywhere in TI's tree showing WL1837 BT enablement on the SK-AM62 UART1 path? We could not find one.

Attaching: relevant DTS patch and dmesg/hciconfig output.

CC2755R10: Reference Design Available?

Edgar Serrano Apodaca — Tue, 21 Jul 2026 01:35:28 GMT

Part Number: CC2755R10

Hi team,

Are there any reference designs or user guides for the CC2755x10?

Best,

Edgar

CC2340R5: CC2340R5 13.56MHz LGPT by running external clock through GPIO and event fabric

Rogelio Armino — Mon, 20 Jul 2026 20:08:17 GMT

Part Number: CC2340R5
Other Parts Discussed in Thread: CC2755R10

Hi!

I'm working on a project to give the CC2340R5 capabilities to be a passive NFC tag.
In order for the CC2340 to be able to write back to an NFC reader, I need access to a 13.56MHz clock that I can use to synchronize communication to the reader.
I also need to be able to control the output from a sub-frequency of the 13.56Mhz clock for the communication.

I was thinking of using the event fabric.
The plan would be to route a 13.56Mhz external clock to a GPIO input, then route to the TICKEN input of the LGPT.

Is this possible?
Are there any limitations due to the high frequency or the CC2340 internal clock running at 48MHz?
If I also have a seperate 48MHz powered LGPT, will I essentially be able to operate 2 LGPT's with different fundamental frequencies (48Mhz and 13.56Mhz)?

CC2652R: Meaning of “GAP_CONN_EVT_STAT_MISSED”

Yasukane Yamanaka — Mon, 20 Jul 2026 09:27:03 GMT

Part Number: CC2652R
Other Parts Discussed in Thread: BLE-STACK

I have a question regarding the “Connection Event Report” described in the GAP chapter of the BLE5-Stack User Guide.

The guide explains three possible values for the “status” field in the Connection Event Report.

I would like to ask about the meaning of “GAP_CONN_EVT_STAT_MISSED.”

The explanation states that “The peer device did not show up for the connection event. ,” but is it correct to understand this as “the peer device did not appear in the connection event = there was no ACK from the peer”?

Best regards,

LAUNCHXL-CC2640R2: Compatibility Questions

Saiprabhav Vellala — Fri, 17 Jul 2026 17:21:48 GMT

Part Number: LAUNCHXL-CC2640R2
Other Parts Discussed in Thread: CC2650MODA, , CC2650, CC2640, BLE-STACK

Hi, I had a questions regarding the compatibilty of these two board. Are the LAUNCHXL-CC2640R2, BOOSTXL-CC2650 / CC2650MODA compatible with eacother?

CC2538-CC2592EMK: Urgent _Net weight request from Flex_ TEXAS

Ajmeeri AH — Fri, 17 Jul 2026 12:29:51 GMT

Part Number: CC2538-CC2592EMK

Hi Team,

Good day!

Please provide the Net weight for this PN-CC2340R5MODAN0MHAR in kg

Thansk & Regards,

CC2340R5: How to Generate an RF Carrier in the “basic_ble” Project

js Tan — Thu, 16 Jul 2026 09:56:30 GMT

Part Number: CC2340R5

Hi,

We need to use the `basic_ble` sample project to generate an unmodulated waveform for our production test program. Is this possible?

CC2640R2F: Not able to wake up from StandBy Deepsleep State using gpio

Yash Shah — Thu, 16 Jul 2026 06:25:00 GMT

Part Number: CC2640R2F

Hello,
I am working on TI CC2640R2F Launch Pad.
I am having issue in waking up from standby deep sleep state.
I am trying to wake up using a Button interrupt on BTN-1 or DIO13.
I am using same button for waking up from shutdown mode and it works for shutdown mode.
Here's my code snippet for shutdown mode and stanby mode.

void *mainThread(void *arg0)

{

Semaphore_Params standbySemParams;

Semaphore_Params_init(&standbySemParams);

standbySem = Semaphore_create(0, &standbySemParams, NULL);

/* Call driver init functions */

GPIO_init();

I2C_init();

SPI_init();

UART_init();

GPIO_setConfig(Board_GPIO_LED1, GPIO_CFG_OUT_STD | GPIO_CFG_OUT_LOW);

PIN_Config wakePin[] ={ Board_PIN_BUTTON0 | PIN_INPUT_EN | PIN_PULLUP | PINCC26XX_WAKEUP_NEGEDGE, PIN_TERMINATE};

for (;;) {

switch (appState) {

case APP_STATE_ACTIVE:

{
if (Semaphore_pend(standbySem, BIOS_NO_WAIT)) {

appState = APP_STATE_STANDBY;
}
break;

}

case APP_STATE_SHUTDOWN: //when called Power_shutdown controller wakesup with same wakepin from shutdown and restarts main routine

{

PINCC26XX_setWakeup(wakePin); 👍

Power_shutdown(0, 0); 👍
break;
}

case APP_STATE_STANDBY:

{

GPIO_toggle(Board_GPIO_LED1); /* about to sleep */

Power_sleep(PowerCC26XX_STANDBY); 👎 //problem is here when it enters Power_sleep it goes into deepsleep mode and never responds to button press interrupt

GPIO_toggle(Board_GPIO_LED1); /* wakeup from sleep */ 👎

break;
}

}
}
}

Power_sleep gets stuck inside PRCMDeepSleep
/* 13. Invoke deep sleep to go to STANDBY */

PRCMDeepSleep();

What could be possible solution to wakeup from deepsleep standby using wakeup pin and LED1 toggle activates which stands right after Power_sleep() call?
Thanks

CC2340R2: How to configure RF channel (0, 19, 39) using host_test/BTool

Shivam Kumar — Thu, 16 Jul 2026 06:12:08 GMT

Part Number: CC2340R2

Hi TI Team,

I am working on a custom product based on the CC2340R2 using the SimpleLink Low Power F3 SDK.

Our module is currently undergoing WPC RF certification. The test lab has asked us to configure the module to transmit on the following BLE RF channels for radiated testing:

Channel 0 (2402 MHz)
Channel 19 (2440 MHz)
Channel 39 (2480 MHz)

From my investigation, I found:

The host_test application can be used together with BTool.
In the Bluetooth HCI command list, I found the following standard LE test commands:
- LE Receiver Test
- LE Transmitter Test
- LE Test End

However, I could not find any documentation explaining how to actually select RF Channel 0, 19, or 39 using host_test and BTool.

My questions are:

Is host_test the recommended firmware for RF certification (WPC) on the CC2340R2?
Should I use the standard LE Transmitter Test command or the TI vendor-specific HCI_EXT_ModemTestTxCmd for radiated RF testing?
How can I configure the radio to transmit on:
- Channel 0 (2402 MHz)
- Channel 19 (2440 MHz)
- Channel 39 (2480 MHz)?
Is this done through a specific BTool menu, or do I need to manually send HCI commands?
Is there any TI application note or example that demonstrates this procedure?

Any guidance or example would be greatly appreciated.

Regards,

Shivam

CC2340R5: MCU working current consumption

Albin Zhang — Thu, 16 Jul 2026 05:26:32 GMT

Part Number: CC2340R5
Other Parts Discussed in Thread: ENERGYTRACE

Hi experts,

based on the datasheet, the MCU active current is 2.6mA. But customer's board current is 3.7mA.

Could you share your insights, what's the possible extra internal block working will introduce the delta 1.1mA?

BTW, there is not RF working
TI's SDK basic BLE is okay with minimum change to active MCU, working good on customers board. 2.6mA,
already cut all of the DIOs and configure the DIO to input/no pull.
tried to de-porting some of drivers, e.g. I2C, UART, Timer, Known applicaion tasks, no improvement.

BR. Albin

CC2652R: Regarding the Counters Returned by the “HCI_EXT_GetTxStatisticsCmd” Command

Yasukane Yamanaka — Wed, 15 Jul 2026 10:28:54 GMT

Part Number: CC2652R

I was told that I can retrieve statistical information using the “HCI_EXT_GetTxStatisticsCmd” command, and I was provided with the link below.

https://dev.ti.com/tirex/content/simplelink_cc13xx_cc26xx_sdk_8_32_00_07/docs/ble5stack/vendor_specific_guide/BLE_Vendor_Specific_HCI_Guide/hci_ext_api.html#hci-ext-gettxstatisticscmd

The link states that statistics can be retrieved in 16-bit format, but is the breakdown of those 16 bits specified anywhere?

By “breakdown,” I mean, for example, that “Total Valid Packets” corresponds to bits 0–3 of the 16-bit value.

Or does it mean that each individual statistic is a 16-bit counter?

Best regards,

CC2340R5MODA: unexpected configuration appears CPUIRQ0SEL

Jan Bock — Tue, 14 Jul 2026 17:38:00 GMT

Part Number: CC2340R5MODA
Other Parts Discussed in Thread: CC2340R5

We have been observing some unexpected behavior on the CC2340R5.

We successfully configured wake-up from standby using a GPIO interrupt (via GPIO_setCallback and GPIO_enableInt). However, in some cases, the device hangs after the GPIO is toggled.

After further investigation, we found that execution ends up in the default ISR for CPUIRQ0 - Exception_handlerSpin() - as configured in ti_freertos_config.c.

While debugging the issue, we noticed that the CPUIRQ0SEL register is set to 0x9 (GPIO_COMB). As far as we are aware, neither our application nor the TI software stack explicitly modifies this register. CPUIRQ5SEL seems to be used for the GPIO_COMB in the GPIOLPF3 module. This unexpected configuration appears to be responsible for the interrupt that eventually leads to the exception handler.

What is particularly strange is that the issue disappears after a power cycle, but reappears after attaching a debugger and issuing a software reset.

Do you have any idea what could cause CPUIRQ0SEL to be configured this way after flashing or a software reset? For now, I am running the following at bootloader startup:

EVTSVTConfigureEvent(EVTSVT_SUB_CPUIRQ0, EVTSVT_PUB_NONE);

This workaround resolves the issue, but I would like to understand the root cause. Could this occur through any other means, and are there any other potential side effects or unexpected behaviors we should be aware of?

Any insights would be greatly appreciated.

CC2340R5: continuous wave test will stop after around 5 minutes

Jerry Kuo — Tue, 14 Jul 2026 09:03:22 GMT

Part Number: CC2340R5

Hi team,

My customer is doing CC2340R5 certification test. They use HCIExt_EnhancedModemTestTxCmd to start TX and HCIExt_SetTxPowerDbmCmd to set the power.
On the spectrum analyzer, they observed that the TX power at the target frequency drops to background levels around 4 to 5 minutes after the HCI command is executed.

In the test, customer need to set frequency, data rate, and get strong enough power for the certification
Are above two HCI commands the correct ones for certification?

CC2440R5 SDK: ver7.40

CC2640: debug cannot start

luigi Desiderato — Mon, 13 Jul 2026 12:47:13 GMT

Part Number: CC2640
Other Parts Discussed in Thread: SYSBIOS

On a custom board populated with CC2642 I have to debug it through Launchpad emulator XDS110.

1st of all I imported "project_zero" app. There are two cases arising:

1) compiling original code, no errors arise but it is impossible to debug it because of a different target. This is the diagnostic:

Cortex_M3_0: GEL Output: Memory Map Initialization Complete.
Cortex_M3_0: Device revision '0x4' unknown for selected target. Assuming latest known revision: Rev. 2.4.
Cortex_M3_0: GEL Output: Board Reset Complete.
Cortex_M3_0: Command=20 -- addr=0x00002000 -- length=0x00001000
Cortex_M3_0: File Loader: Memory write failed: Status 0x0102: Target flashloader failed to erase sector 1. Low level function returned status 3 (Incorrect parameter value).
Cortex_M3_0: GEL: File: H:\Move\Software\ble5_project_zero_cc2640r2lp_app\FlashROM_StackLibrary\ble5_project_zero_cc2640r2lp_app.out: Load failed.

Note no linker cmmand file is available in the same tab

2) if in the property CCS general tab I change the target processor to CC2642R1F, the compilation ends with the following diagnostic:

<Linking>
"C:/ti/simplelink_cc2640r2_sdk_5_30_00_03/source/ti/ble5stack/common/cc26xx/ccs/cc26xx_app.cmd", line 254: error #10263: FLASH memory range has already been specified
"C:/ti/simplelink_cc2640r2_sdk_5_30_00_03/source/ti/ble5stack/common/cc26xx/ccs/cc26xx_app.cmd", line 254: error #10264: FLASH memory range overlaps existing memory range FLASH
"C:/ti/simplelink_cc2640r2_sdk_5_30_00_03/source/ti/ble5stack/common/cc26xx/ccs/cc26xx_app.cmd", line 257: error #10264: FLASH_LAST_PAGE memory range overlaps existing memory range FLASH
"C:/ti/simplelink_cc2640r2_sdk_5_30_00_03/source/ti/ble5stack/common/cc26xx/ccs/cc26xx_app.cmd", line 260: error #10263: SRAM memory range has already been specified
"C:/ti/simplelink_cc2640r2_sdk_5_30_00_03/source/ti/ble5stack/common/cc26xx/ccs/cc26xx_app.cmd", line 260: error #10264: SRAM memory range overlaps existing memory range SRAM
"C:/ti/simplelink_cc2640r2_sdk_5_30_00_03/source/ti/ble5stack/common/cc26xx/ccs/cc26xx_app.cmd", line 206: warning #10190-D: absolute symbol "__STACK_TOP" being redefined
"C:/ti/simplelink_cc2640r2_sdk_5_30_00_03/source/ti/ble5stack/common/cc26xx/ccs/cc26xx_app.cmd", line 206: warning #10190-D: absolute symbol "__STACK_TOP" being redefined
"C:/ti/simplelink_cc2640r2_sdk_5_30_00_03/source/ti/ble5stack/common/cc26xx/ccs/cc26xx_app.cmd", line 206: warning #10190-D: absolute symbol "__STACK_TOP" being redefined
error #10010: errors encountered during linking; "ble5_project_zero_cc2640r2lp_app.out" not built

>> Compilation failure
makefile:187: recipe for target 'ble5_project_zero_cc2640r2lp_app.out' failed
gmake[1]: *** [ble5_project_zero_cc2640r2lp_app.out] Error 1
makefile:180: recipe for target 'all' failed
gmake: *** [all] Error 2

* Build Finished *

So I cannot debug either. Note the linker file in this second case is changed to cc26x2r1f.cmd
Any idea? Thanks Luigi

CC2744R7-Q1: the random number generation sequence in the TI OSAL layer.

Kai Kim — Mon, 13 Jul 2026 11:32:38 GMT

Part Number: CC2744R7-Q1
Other Parts Discussed in Thread: SYSCONFIG

Hi Team,

Currently, the application uses the following API (osal_rand) to generate random numbers.

Could you please confirm the random number generation sequence of this API? Specifically, please clarify whether it uses a TRNG + DRBG combination or generates random numbers using TRNG alone, etc.

(it is required to use TRNG + DRBG)

For reference, TRNG is enabled in the ti_driver section of SysConfig. (DRBG does not have a separate configuration option, so it was not configured.)

Best Regards,
Kai Kim

CC2745R10-Q1: Question in HSMXXF3.c on HSMXXF3_isStandaloneDMASupportEnabled() with HSM version 3.4.5

Connor — Mon, 13 Jul 2026 02:49:53 GMT

Part Number: CC2745R10-Q1

Hi team,

I found something strange that, with HSM FW 3.4.5, HSMXXF3_isStandaloneDMASupportEnabled will not return true, causing ECDHXXF3HSM_initializeHSMOperations() will not release the CommonResourceXXF3_accessSemaphore. Could the team check the possibility of my notice?

Thanks!

Best Regards,

Connor

CC2745R7-Q1: Guidance Required for Migrating Project from CC2745R10 to CC2745R7

Ratan Dalei — Fri, 10 Jul 2026 12:23:08 GMT

Part Number: CC2745R7-Q1
Other Parts Discussed in Thread: SYSCONFIG,

Hello TI Team,

We have developed our custom board using the CC2745R7 device. Previously, we were using the CC2745R10 LaunchPad for development, and all of our existing software is configured for the CC2745R10.

Could you please guide us on how to migrate the project from CC2745R10 to CC2745R7? Specifically, we would like to know:

Where do we need to change the target device from CC2745R10 to CC2745R7?
Are there any project settings, SysConfig changes, or configuration files that need to be updated?
Are there any additional steps or considerations required during the migration?

Please suggest the recommended approach for this migration.

Thanks & Regards
Ratan.

CC2642R: load capacitance HSE 48MHz crystal -performance issues

Jan Bock — Fri, 10 Jul 2026 11:25:48 GMT

Part Number: CC2642R
Other Parts Discussed in Thread: SYSCONFIG

We have been experiencing a strange issue with the BLE performance and are therefore looking for solutions.

We think we might have a HW solution, but we are also looking for a SW solution for the devices in the field.

The issue is related to the loading capacitance on the HSE 48MHz crystal.

We see that the loading capacitance adds a frequency shift to the set channel and frequency.

We suspect that the internal capacitance is enabled and is therefore increasing the capacitance that is causing the drift.

We have tried to modify that value a bit, and have seen a positive impact.

MODE_CONF is the register we modify to set the cap array tuning to a negative value (signed 8-bit)

Questions;

Whats the lowest acceptable value that we can set? How can we disable it completely?
Is there a way to add a frequency offset to the BLE channel?
Could you modify the CCFG value over UART on the fly? Perhaps not.