蓝牙论坛 - 最近的话题

CC2340R5: standby低功耗电流

zhou lele — Mon, 18 May 2026 01:02:47 GMT

Part Number: CC2340R5

我用的是cc2340R5 basic_ble进行开发，我现在需要进入低功耗，我通过代码调试发现我的代码在进入idle后进入了PowerLPF3_sleep(soonestDelta + sysTimerCurrTime);这个睡眠，正常来说此时应该进入了低功耗，但是我通过万用表测出我的电流还是有十几毫安，我想知道这个睡眠模式下的电流应该是多少，我怎么才能让它的电流掉下去呢

CC2642R: CC2642R数据传输问题

yi ouyang — Wed, 13 May 2026 05:46:50 GMT

Part Number: CC2642R

我想做一个持续的数据传输的应用，我在simpleperipheral的例程中修改定时器

周期SP_PERIODIC_EVT_PERIOD和发送的notify数据char4的长度，在数据长度为220的情况下，定时器周期在200ms以下就无法连接到windows的ble助手了，但使用安卓的ble助手却能够正常连接。我期望的发送周期时40ms。请问应该怎么修改程序？

CC2340R5: 如何彻底关闭cc2340的射频部分

Vivian — Tue, 12 May 2026 11:57:28 GMT

Part Number: CC2340R5

我使用的是CC2340进行开发，SDK版本是8.20，现在·我想知道如何使模块上的射频部分完全掉电，但是其余的功能能够正常使用，比如其他的FreeRTOS任务，只有蓝牙方面的功能完全失效，我尝试过使用BLEAppUtil_advStop ，这个API能够完全将射频部分关闭吗?

CC256XCQFN-EM: CC256XCQFN-EM模块是否支持CTKD功能

Zeng Zhishan — Fri, 17 Apr 2026 03:35:40 GMT

Part Number: CC256XCQFN-EM
Other Parts Discussed in Thread: CC2564C,

TI技术团队，你好

我们在使用CC256XCQFN-EM模块的过程中遇到了问题，我们想使用蓝牙协议的CTKD功能，但是没有在CC2564C芯片手册和历程中找到关于CTKD功能的描述。请问是不是CC2654C芯片不支持CTKD功能。

此致，谢谢！

CC2340R5: 怎么确定CC2340R5从机扩展广播是否启用成功？以及如何使用主机与之建立连接？

xiong luo — Fri, 10 Apr 2026 10:51:08 GMT

Part Number: CC2340R5

SDK版本:simplelink_lowpower_f3_sdk_9_14_00_41。基于basic_ble示例启用Extended Advertising ，按照上述配置从机和主机，在主机端无法扫描到从机广播。也无法确认从机是否广播成功。

1.如何在从机端实现基于CodedPHY的扩展广播？

2.如何在主机端实现CodedPHY扩展广播的连接？

CC256XCQFN-EM: LinuxSPPM和LinuxDEVM是否支持获取CC256XCQFN-EM模块的蓝牙收发状态

Zeng Zhishan — Wed, 01 Apr 2026 07:12:46 GMT

Part Number: CC256XCQFN-EM
Other Parts Discussed in Thread: CC2564C

Hello TI Technical Support Team,

I am encountering an issue while using the CC256XCQFN-EM module. I would like to inquire whether LinuxSPPM and LinuxDEVM support retrieving the Bluetooth transmit/receive status information of the CC256XCQFN-EM module. I need to obtain the transmit/receive status of the Bluetooth module to enable other chips accordingly.

If these two components do not support retrieving the transmit/receive status, could you please advise if there are alternative methods to determine the transmit/receive status of the CC256XCQFN-EM module or the CC2564C chip?

Thank you!

TI技术支持团队你好，

我在使用CC256XCQFN-EM模块时遇到了问题，想询问一下LinuxSPPM和LinuxDEVM是否支持获取CC256XCQFN-EM模块的蓝牙收发状态信息，我需要获取蓝牙模块的收发状态以便于给其它芯片进行使能。如果这两个组件不支持获取收发状态，是否有其它方法可以知道CC256XCQFN-EM模块或者CC2564C芯片的收发状态。

感谢！

CC2745R10-Q1: CC2745 TRNG模块open失败

Hongrui Zhao — Tue, 10 Mar 2026 09:10:22 GMT

Part Number: CC2745R10-Q1

"您好，我正在使用CCS20.3版本+SimpLink F3 Sdk 9.14+empty实例工程开发CC2745的软件。目前碰到的问题是当我在syscfg中增加RNG和TRNG模块后，参照例程实现流程open后返回handle为0，开启失败。图中为我对.syscfg的配置与代码实现。想请教下是什么原因导致的(未使用BLE Stack)，谢谢！ "哈喽，我之前提过了这个问题，我根据官方提到的帖子中解决办法在RTOS建立后再按照demo中的步骤open了RNG模块，但仍返回Handle为NULL，我也在SYSCFG中添加了多个RNG模块，但都无法open。想请教下该模块是否与其他模块有相关性？我在Debug中观察到在open过程中在红框处init失败了。

CC2340R5-Q1: OAD slot-size問題

Feng Cheng Lin — Thu, 05 Mar 2026 03:10:24 GMT

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

我在範例(basic_ble_oad_onchip)裡面有幾個我看不太懂，以下是我不懂的地方

cc2340_freertos.cmd裡面的APP_Size我算完之後是0x4AF00
sysconfig的NVS設定是Region Type = Pointer, Region Base = 0x32000, Region Size = 0x4A000
imgtool的指令是C:/ti/simplelink_lowpower_f3_sdk_9_14_00_41/tools/common/mcuboot/imgtool sign --header-size 0x100 --align 4 --slot-size 0x4A000 --version 1.0.0 --pad-header --key C:/ti/simplelink_lowpower_f3_sdk_9_14_00_41/source/third_party/mcuboot/root-ec-p256.pem basic_ble_oad_onchip_9_14_00_41_noheader.bin basic_ble_oad_onchip_9_14_00_41_v1.bin

由第1點來看APP_Size是0x4AF00，可是第2點的sysconfig設定0x4A000，及第3點的-slot-size也是0x4A000, 為什麼第1點的Size和第2及第3點會對應不起來？

CC2745R10-Q1: CC2745R10-Q1 CCFG和SCFG区域擦除烧录相关问题

xu chengjun — Sat, 28 Feb 2026 05:43:41 GMT

Part Number: CC2745R10-Q1

TI技术支持，

您好！

我从CC2745R10-Q1的相关资料的SACI指令中只看到了ERASE_CHIP指令和ERASE_MAIN指令，请问下是否存在单独只擦除CCFG和SCFG区域的指令，在不动FLASH区域已有的数据的情况下，将CCFG和SCFG区域数据清除并写入新值？

谢谢

CC2745R7-Q1: CC2745R7-Q1固件编译和烧录问题

snail leo — Thu, 12 Feb 2026 05:22:46 GMT

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

sdk固件版本路：simplelink_lowpower_f3_sdk_9_14_01_16 下的basic_ble工程

uniflash工具版本：9.4.1.5566

问题描述：

我们的cc2745r7样件回板，准备进行dv测试，在使用uniflash工具烧录编译的basic_ble 工程后，无法扫描到ble广播，进行 debug时，无法卡在main入口，直接进入Exception_handlerSpin函数

我们尝试更换样件上的芯片为cc2745r10后，烧录相同的固件可以扫描到对应的ble广播，芯片启动正

（使用uniflash工具在更换芯片前后都可以读到芯片的信息和hsm版本号，可以证明工具和固件烧录没有问题）

可能的排查方向：

1、贵司官网提供的cc2745 sdk是基于r10的工程，对于编译和使用r7芯片时，有没有使用时要求或限制？请帮忙确认一下。

2、debug时，使用的也是r10的工程，是不是也有对应改成r7的debug的模式或方法？请帮忙确认一下。

3、后续调试时，发现编译工程的syscfg文件中，有一个修改芯片平台的选项，改为cc2745r7后，可以进行debug调试，但是走到main函数的rtos调度后，会立即进入Exception_handlerSpin函数，我想应该还有别的地方需要一起修改，请帮忙确认一下。

CC2745R10-Q1: CCS中修改MCUboot App配置

Hongrui Zhao — Mon, 02 Feb 2026 10:58:04 GMT

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

Hi，

我正在使用CCS20.4与Simplink low power 9.14的SDK开发CC2745的程序。目前需要修改MCUboot App中的Base address和 Slot size的大小。想请教一下红框中的描述是否有具体指导做法》我目前只找到了txt文件，但不清楚如何放到imgtool sign中

CC2541: BLE-CC254x-1.5.2.0后续还有更新吗？

关东糖 — Fri, 23 Jan 2026 14:38:59 GMT

Part Number: CC2541

如题，看到release note中还有issue，还会修复吗？

CC2745R10-Q1: syscfg中广播配置生成数据异常确认

snail leo — Tue, 20 Jan 2026 02:57:35 GMT

Part Number: CC2745R10-Q1

你好，我通过syscfg配置了广播数据，使用的是厂商自定义数据，但是编译生成的ti_ble_config.c文件中，adv_Data1变量的长度不符合ble广播规范，会在数据末尾自动添加一个0x00字节的数据，这个是否是正常的？

CC2674P10: BLE发送数据分包问题

rui wang — Fri, 16 Jan 2026 12:48:07 GMT

Part Number: CC2674P10

您好，我最近在使用CC2674P10的两个设备之间进行通信，其中从机设备要把前级采集的数据发送，每组400字节的数据，但是MTU最大是255，所以考虑到需要分包发送。我按照下面图片中的代码进行发送，即再在一次连接事件中发送两次数据包，我通过一个while循环发送了两次，但是我在主机端进行测试的时候发现会增加丢包率，前面数据丢包率是0，通过这个方法传输完一户丢包率会增加到百分之2，所以想咨询如果对于数据量>MTU的情况怎么发送呢？

CC2745R10-Q1: CC2745如何禁用SWD接口

Hongrui Zhao — Tue, 06 Jan 2026 02:20:37 GMT

Part Number: CC2745R10-Q1

Hi,我目前正在基于CC2745R10开发基础功能，想向官方技术支持请教一下如何在程序烧录后禁用SWD接口功能？我在CCS20.4的IDE的SYSCFG功能中看到了图一这个选项，但我没有找到在程序中如何使用的。请帮忙回答下这两个问题：

该.syscfg文件中对CCFG.scfgAllowDebugPort = false;这个禁用就可以直接映射到TRM中SCFG寄存器的allowDebugPort 这位吗(图二所示)，是否配置这位为FALSE后就可以实现我禁用Debug的需求？因为我在TRM 5.6章节看是需要修改CCFG寄存器（图三），所以是改CCFG/SCFG都可以实现该功能吗？
如何该配置无法满足需求，我还需要配置哪些寄存器可以实现我的需求？

图一

图二

图三

CC2745R10-Q1: channel sounding compensation frequency

zheng zhang — Sun, 04 Jan 2026 13:37:05 GMT

Part Number: CC2745R10-Q1

我目前在使用cc2745R10-Q1进行信道探测任务时，我们注意到在输出输出中，有一个compensation frequency参数这个参数的量总是在32000上下浮动，我想请问这个compensation frequency具体代表了什么意思呢，他在remote设备和local设备进行距离估计时，起到了哪些作用？

CC2642R-Q1: 蓝牙模组&数字钥匙场景

chen kai — Wed, 31 Dec 2025 07:29:50 GMT

Part Number: CC2642R-Q1

问题背景：
在最近一次技术会议后，客户方按TI建议将通信门限SCA从50PPM调整至500ppm。团队人工已进行200次自测，未发现问题。随后客户使用机器人进行连续压测，在约130次测试中遇到一次异常，现象与之前反馈的问题一致。但此次异常发生时未能捕获空口数据包，因此无法进一步分析。测试过程中，芯片工作温度约为37°C，设备处于持续上电、连续运行状态。

问题描述与分析：
我们注意到，根据近期摸底测试，在37°C环境下，32K时钟精度通常应在50ppm以内。目前客户已将门限放宽至500ppm，若仍为32K精度问题，则怀疑是否因设备长时间连续工作（包括钥匙端与车端蓝牙持续运行）导致时钟误差累积所致。如果纯粹是硬件层面的时钟偏差，可能难以根本解决。

咨询方向：

此类连续运行场景下，是否可能存在由不同时钟源长期累积误差引起的通信异常？
从系统或软件层面，是否有可行的缓解策略？例如定时复位、时钟同步校准等机制，以减少累积误差对通信的影响。
在无法捕获空口包的情况下，建议如何进一步定位问题？

希望得到贵方在类似场景下的经验分享与技术建议，谢谢！

CC2652PSIP: 主协处理器公用ADC导致概率性死机

luck luck — Fri, 19 Dec 2025 10:12:15 GMT

Part Number: CC2652PSIP

你好！主核ADC采集电池电压协处理器采集一个外部电压信号运行过程中概率性死机后面开协处理器的时候主核不采集就不死机不清楚什么问题导致死机是主核和协处理器不能共用硬件外设资源吗？

CC2745R10-Q1: CC2745R10：basic_ble例程无法运行

chuanxian zhu — Wed, 17 Dec 2025 13:03:55 GMT

Part Number: CC2745R10-Q1

在CC2745R10-Q1 LaunchPad上运行例程basic_ble_LP_EM_CC2745R10_Q1_freertos_ticlang时报错。

SDK: simplelink_lowpower_f3_sdk_9_14_00_41

CCS 20.4.0

CC2340R5: 蓝牙示例basic_ble中SimpleGattProfile_setParameter(SIMPLEGATTPROFILE_CHAR4, 1,&value)；无法发送通知

honglin liu — Wed, 17 Dec 2025 08:54:27 GMT

Part Number: CC2340R5

测试蓝牙连接，用的是示例basic_ble；在main_freertos.c添加的代码，如下：

static void DataTask(void *pv)

{

uint8_t cnt = 0;

char dataBuffer[64];

// 再等待一段时间确保 linkDB 初始化

vTaskDelay(pdMS_TO_TICKS(2000));

for (;;)

{

vTaskDelay(pdMS_TO_TICKS(1000));

if (BLE_IS_CONNECTED())

{

txBuf[0] = cnt++;

SimpleGattProfile_setParameter(SIMPLEGATTPROFILE_CHAR3, 1, txBuf);

//SimpleGattProfile_setParameter(SIMPLEGATTPROFILE_CHAR4, 1,txBuf);

}

else

{

printf("No BLE connection - skip notify\r\n");

}

void SimpleData_start(void)

{

printf("BLUE-SimpleData_start\r\n");

xTaskCreate(DataTask, "DataTask", 1024, NULL, 0, NULL);

}很奇怪的是手机端蓝牙连接后，打开SIMPLEGATTPROFILE_CHAR4的数据接收通知，只能接收一次数据，每次关闭开启数据接收通知才能再次接收到一次数据

CC2745R10-Q1: AoA定位蓝牙问题

Tommy — Mon, 15 Dec 2025 07:23:03 GMT

Part Number: CC2745R10-Q1
Other Parts Discussed in Thread: CC2340R5

Hi E2E,

请教一下为了得到更好的AoA定位信号，计划采用cc2745，该芯片支持BLE6.0通讯，提升定位效果。

这一应用是用在汽车车身和钥匙模块两端的，因为成本原因，想要问一下：

能否采用cc2745作为车身上的锚点，而车钥匙上面采用cc2340这种低成本的BLE 5.4来做？

这种组合与车身和钥匙都采用cc2745有哪些性能上的区别？

谢谢！

CC2340R5: J-Link Unlock Procedure under Password Protection Mode

Qingtian Yang — Wed, 10 Dec 2025 00:52:49 GMT

Part Number: CC2340R5
Other Parts Discussed in Thread: UNIFLASH

While you pointed us to the relevant documentation, the manual process of switching APs and writing registers within the J-Link Commander environment is proving to be extremely *** and prone to error in real-world use.

To quickly validate the entire password authentication procedure and its expected behavior, could you please provide a simple operational guide using the official TI development kit (e.g., CCS or UniFlash with an XDS110 debugger) to perform the password authentication on CC2340?

If the official TI tools have a feature that handles this process automatically, it would serve as an effective validation benchmark. Once we confirm the correct authentication process using the official tools, I can then use them to validate my product and even explore the implementation of the same function using J-Link.

We look forward to your continued support. Thank you

CC2340R5: CC2340R53 怎么在BLE广播、扫描、连接的时候进入低功耗？

xiong luo — Tue, 09 Dec 2025 08:49:25 GMT

Part Number: CC2340R5
Other Parts Discussed in Thread: SYSCONFIG

根据以前的经验，想要降低功耗只需要开启power saving然后将外设关闭，电流就会从mA降低到uA级别。之前在V8.4的版本中调试过CC2340R52的低功耗，按照此方法保持BLE广播的情况下关闭外设后电流从2.2mA降低到了12uA，但是将此工程移植到CC2340R53上进入低功耗失效（电流无变化）。CC2340R52与CC2340R53的区别仅仅是flash的大小，直接将CC2340R52能进入低功耗的固件烧录到CC2340R53上面运行，最终也不能进入低功耗（电流无变化）。

另外，将SDK版本从V8.4升级到V9后之前CC2340R52的低功耗代码也不能进入低功耗了。

1.CC2340R53 怎么在BLE广播、扫描、连接的时候进入低功耗？

2.请确认V9版本的代码是否能正常进入低功耗？应该怎么进入低功耗？

CC2745R10-Q1: CC2745 TRNG模块open失败

Hongrui Zhao — Fri, 05 Dec 2025 05:07:14 GMT

Part Number: CC2745R10-Q1

您好，我正在使用CCS20.3版本+SimpLink F3 Sdk 9.14+empty实例工程开发CC2745的软件。目前碰到的问题是当我在syscfg中增加RNG和TRNG模块后，参照例程实现流程open后返回handle为0，开启失败。图中为我对.syscfg的配置与代码实现。想请教下是什么原因导致的(未使用BLE Stack)，谢谢！

CC2340R5: Questions on CC2340 Debug Access Security (CCFG) Configuration and J-Link Unlock Procedure

Qingtian Yang — Thu, 04 Dec 2025 08:54:49 GMT

Part Number: CC2340R5
Other Parts Discussed in Thread: UNIFLASH

Hello TI Team,

I am evaluating the Debug Access security mechanism on the CC2340R5, specifically focusing on the combined behavior of the permissions.allowDebugPort and debugCfg.authorization fields in the CCFG area. I have encountered some procedural questions when using J-Link Commander for both debugging and access recovery, and I would appreciate your official guidance.

My CCFG configurations are primarily discussed in the context of the following two scenarios:

Question 1: J-Link Unlock Procedure under Password Protection Mode

Configuration Status:

CCFG.permissions.allowDebugPort = CCFG_PERMISSION_ALLOW
CCFG.debugCfg.authorization = CCFG_DBGAUTH_REQPWD (Require Password Authentication)

Problem Description:

If my device is programmed and has the AHB-AP (CPU core) locked according to the above configuration, and I know the cleartext password required for unlocking is "Open Sesame!".

Is there an officially recommended or simplified command sequence for J-Link Commander to submit this password via the SACI interface and successfully acquire debug access?
I understand the process requires switching to the SEC-AP (AP #2) and then writing the password as Little-Endian 32-bit words. Could you provide a complete and reliable step-by-step procedure/script for J-Link Commander to complete the unlock process without relying on TI-specific tools (such as CCS or UniFlash)?

Question 2: Non-Erase Recovery Method in DBGFORBID State

Configuration Status:

CCFG.permissions.allowDebugPort = CCFG_PERMISSION_ALLOW (Allow SWD Port)
CCFG.debugCfg.authorization = CCFG_DBGAUTH_DBGFORBID (Debug Forbidden)

Problem Description:

Based on the TRM documentation, under this configuration, the SWD interface remains active, and the device is able to enter SACI mode.

In this Debug Forbidden but not physically disabled state, aside from executing the Chip Erase command (CMD 0x09) via the SACI interface, is there any other non-destructive method to temporarily or permanently regain debug access to the chip? For example, is there a special SACI command or DP/AP register operation that can bypass the DBGFORBID restriction?
We aim to retain a recovery method that is only accessible to TI or authorized users (if such a method exists) while securing the device, without risking data loss (Chip Erase). If no such method exists, does it mean that as long as allowDebugPort is not set to FORBID, Chip Erase is the only available recovery option?

I look forward to your professional guidance and clarification.

Thank you!