CC2640R2F
simplelink_cc2640r2_sdk_ble_example_pack_1_50_00_62
simplelink_cc2640r2_sdk_1_50_00_58
应用场景描述：
通过3个IO口获取数据（驱动已经写好并debug看数据都ok）
1个按键、1个beep、2个led（这些外设也都测了没问题）
问题描述：
debug模式首次配对的时候手机/电脑蓝牙可以连接成功。按键触发中直接执行了HidEmuKbd_sendReport(HID_KEYBOARD_1)，上位机未收到任何东西，蓝牙直接断开，并无法再次连接。
重启debug模式，已配对的设备无法直接连接，须要删除配对重新添加。并且，如果点击已配对设备尝试连接的话，须要删除已配对设备然后再重新开debug，才能正常重新配对连接。
我断点调试了一下，发现是hiddev.c的1500多行中 HidDev_sendNoti(pRpt->handle, len, pData) 这个方法执行导致程序崩溃
不知道这样正常不正常
代码回溯了一下
static void HidEmuKbd_sendReport(uint8_t keycode)
{
uint8_t buf[HID_KEYBOARD_IN_RPT_LEN];
buf[0] = 0; // Modifier keys
buf[1] = 0; // Reserved
buf[2] = keycode; // Keycode 1
buf[3] = 0; // Keycode 2
buf[4] = 0; // Keycode 3
buf[5] = 0; // Keycode 4
buf[6] = 0; // Keycode 5
buf[7] = 0; // Keycode 6
HidDev_Report(HID_RPT_ID_KEY_IN, HID_REPORT_TYPE_INPUT,
HID_KEYBOARD_IN_RPT_LEN, buf);
}
这个方法我记得不是我写的，是官方例子带的吧，这个应该没问题吧？
但是我看上边debug信息 *pData是0x00
不知道是这中间有问题还是说pData就是从0发到7的？
我继续断点发现
static uint8_t HidDev_sendNoti(uint16_t handle, uint8_t len, uint8_t *pData)
{
uint8_t status;
attHandleValueNoti_t noti;
noti.pValue = GATT_bm_alloc(gapConnHandle, ATT_HANDLE_VALUE_NOTI, len, NULL);
if (noti.pValue != NULL)
{
noti.handle = handle;
noti.len = len;
memcpy(noti.pValue, pData, len);
// Send notification
status = GATT_Notification(gapConnHandle, ¬i, FALSE);
if (status != SUCCESS)
{
GATT_bm_free((gattMsg_t *)¬i, ATT_HANDLE_VALUE_NOTI);
}
}
else
{
status = bleMemAllocError;
}
return status;
}
status = GATT_Notification(gapConnHandle, ¬i, FALSE); 执行这句的时候
uint32_t icall_directAPI( uint8_t service , icall_lite_id_t id, ... )
{
va_list argp;
uint32_t res;
icallLiteMsg_t liteMsg;
// The following will push all parameter in the runtime stack.
// This need to be call before any other local declaration of variable....
va_start(argp, id);
// Test that the API is not called in a Hwi or Swi context
{
BIOS_ThreadType threadtype = BIOS_getThreadType();
if (threadtype == BIOS_ThreadType_Hwi ||
threadtype == BIOS_ThreadType_Swi)
{
#ifdef HALNODEBUG
#else /* ! HALNODEBUG */
ICall_abort();
#endif /* HALNODEBUG */
}
}
这里跳转到了ICall_abort();
threadtype 值如下图
查了一下1好像是BIOS_ThreadType_Swi
网上搜了半天没看懂swi是什么意思，好像是跟进程阻塞有关系？