The CC2640R2L enters low-power sleep with a normal current of 1.5ua, the same procedure and operation, batch TI 368, TI 388 power consumption of 100ua+

如题，实现

之前做FCC认证，定频实现是 HCI_EXT_ModemTestTxCmd(HCI_EXT_TX_UNMODULATED_CARRIER,0);

不知道KC咋实现的，希望告知下。

您好，我目前有一个文件在CCFG区域设置了对Sector0与CCFG区域设置了读保护，这导致我在执行sector擦除时擦除失败。我查看了Reference Manual，其中表明进行mass erase或对CCFG区域进行擦除可以接触读保护，但由于我的CCFG区域设置了保护导致对该区域的擦除无法进行。并且，我在Reference Manual中并没有找到关于mass erase的相关信息…

我使用TICC2642的开发板三块，分别烧写host_test和 simple_peripheral和connection_monitor的demo ,烧写后按照connection_monitor的用户指南执行监控连接流程

是在CC2642平台运行的，但是脚本使用的是CC2640的SDK提供的npi_cm_host.exe，因为CC2642并未提供相关工具，

但是运行中出现了错误…

使用BLE的Notify功能，通过定时器每隔10ms向手机发送一包数据，每包数据20字节，发送大约4000包后出现丢包情况，每次丢1包，再次发送大约2000包后再丢一包，这种情况是为什么呢？

当前的连接间隔：

// Minimum connection interval (units of 1.25ms, 80=100ms) for automatic
// parameter update request
#define DEFAULT_DESIRED_MIN_CONN_INTERVAL…

普通simple_peripheral的例程，需要将返回包关闭，同时保证蓝牙是可连接的，如何修改蓝牙初始化配置参数？

你好，如何访问uart外设的Line-break功能？ 我们需要使用它来实现LIN总线的break信号

未在#include DeviceFamily_constructPath(driverlib/uart.h)等uart相关API中找到关于break相关的硬件操作接口,如 UARTBreakCtl()，没有相关接口

能指点一下吗？

C:/Users/ /Desktop/2640sh/../_BLE_SDK_3_30_00_20/source/ti/blestack/../../../tools/blestack/lib_search/lib_search
C:/Users/ /Desktop/2640sh/_BLE-CCS8-SDK3.30/ _SW_BLE-CCS8-SDK3.30/_BLE_STACK…

使用CC2640做的小板子，在CCS下载了simple_peripheral后编译通过烧录后无法正常运行，程序卡在

/*
 *  ======== CC2640R2_LAUNCHXL_initGeneral ========
 */
void CC2640R2_LAUNCHXL_initGeneral(void)
{
    Power_init…

我該如何修改CC2340的MAC Address變成我自己要的?

CCS启动调试点击运行之后，几十秒后连接断开，报错信息如下：

Cortex_M3_0: GEL Output: Memory Map Initialization Complete.
Cortex_M3_0: GEL Output: Board Reset Complete.
CS_DAP_0: Power Failure on Target CPU: (Error -180 @ 0x0) The controller has detected a target…

在使用2640串口时，配置为回调方式并开启部分返回功能接收不定长字符串，正常情况下2640串口收到一个字符串，可以一包收到，但是当发送方发送的字符之间延时稍大，2640的接收就会分包，这个应该是部分返回功能导致的，我想知道部分返回功能是什么原理，是超过一定时间没有接收到下一个字节就会返回吗？还是有其他判断方式进行部分返回？

代码如下：

// Callback function
static void UartreadCallback(UART_Handle…

想問一下 我想讓sem_wait()等待30ms之後就跳出來 我該怎麼設定?
我看了一下原本是semaphorePend(obj->sem, portMAX_DELAY);
#define portMAX_DELAY 0xffffffffUL
這是以 System Clock 1/48M 去算的嗎?

您好, 我目前使用 OAD 範例專案開發.

開發過程,都是使用 UniFlash 並個別燒錄三個檔案.

想請問,

(1) 要如何將此三個檔案 結合成一隻 生產用的燒錄檔, 像是 (JTAG / SWD) 燒錄?

(2) 要如何將燒錄檔寫入保護? 

~~ 以上問題,謝謝!! ~~

Where is CC2340R5 RTC sample in sdk or anywhere?
And How to config RTC in CC2340R5?

like this web to teach to config RTC【BLE-CC2640】CC2640之RTC_cc2640 rtc-CSDN博客

CC2640WatchDog初始化中，在Watchdog_Open()中死机。原代码及死机位置如下。

Watchdog_Handle handle = NULL;
Watchdog_Params params;
uint32_t tickValue;

void WatchDog_Init()
{
Watchdog_Params_init(&params);
params.callbackFxn = watchdogCallback;
params.resetMode…

工程文件为：simple_peripheral_5.1 

协议栈版本：simplelink_cc2640r2_sdk_4_30_00_08

按照官方手册《在无 32kHz 晶体的 CC2640 上运行低功耗 Bluetooth》上使能了内部RC，并按照 针对信标/广播设备应用的更改 要求修改配置参数。

修改后，功耗正常，但建立蓝牙连接后只能保持15s左右的连接时间，然后自动断开连接…

我用CC2640F128芯片模块，一个做主机，一个做从机进行简单通信。是否有办法可以让从机广播时候，不让PC或者手机连接？

手册上说DCDC的效率比LDO高，但是在VDDS小于2V的时候LDO效率高。能提供下，这两个供电方式的具体功耗吗？我想评价下，如果我使用2.5V供电，那两个效率差多少，是否可以接受。

你好，我当前用CC2640F128做一个遥控器，采用充电电池供电。我的芯片除了会对电池电压采集之外，并没有对电池做电源管理电路部分。现在出现这样一种情况，插着电池，对其充电的时候，充完电会出现不工作，重新插一下充电，又可以开始工作了。我尝试把电池去了，用一个外界的小电源，直接接到电池连接口，通上电的是时候，大部分场景下都是可以正常工作的，但是偶然性也会出现不工作的情况。且遥控器正常长期供电的情况下，并没有出现死机现象。请问这种死机可能原因有哪些？

另外，目前我使用的SDK，如果做透传，单次可以发送20个字节，如何设置，可以让我单次发送的字节数大于这个？我记得好像有文章写道，可以设到200多字节。

我现在用CC2640F128模块做蓝牙主机，用它扫描连接同样是CC2640F128的蓝牙从机。想通过对从机用特定的名称开头来识别区分，从而让主机开始配对的时候，优先去连接这个设备。如何做？

如何从扫描到的清单中读取到从设备的名称？

你好，我现在需要用CC2640F128做串口的高速透传，速率能做到多少？如何设置相应的参数？我当前用的是ble_sdk_2_02_01_18这个SDK，好像单次发送字节不能超过20个？这个可以在哪修改？

我目前在基于CC2640F128做一个蓝牙遥控器项目，一个模块做主机，一个做从机。经常有这种现象。原先两个设备正常烧录可以正常配对和绑定，也可以正常通信。但是如果将从设备重新烧录固件，一模一样的固件。出现二者不断连接，又断开。提示REASON 22的错误。并且两个设备重新断电重启都没有用。然后将主机或者从机重新烧录或者随便改一点无关的代码，重新烧录就又大概率的OK了。这种原因大概什么呢？由于这种现象很随机，并且，一模一样的固件，或者固件稍微改点又行了。但过一会重新烧一下又不行了…

在做SRRC测试认证时，测出射频频率偏低。

然后，按照论坛里的方法调整如此下的宏：

#ifndef SET_CCFG_MODE_CONF_XOSC_CAP_MOD
#define SET_CCFG_MODE_CONF_XOSC_CAP_MOD              0x0        // Apply cap-array delta
//#define SET_CCFG_MODE_CONF_XOSC_CAP_MOD                 0x1        // Don't apply cap-array delta …