[参考译文] CC2640R2F：在 A 之后发生了 HW_FAIL_INGABLE_PKT_LEN

器件型号：CC2640R2F

工具与软件：

您好！

我将使用 simplelink_cc2640r2_sdk_5_30_00_03、blestack not ble5stack 用于我们的外设产品。

我 更新了我们产品的固件、然后 市场上出现了 HW_FAIL_INGABLE_PKT_LEN。

我认为此问题与引用的线程相同、并且在  cc2640r2_sdk 上未解决。 对吗？ 已修补的 SDK 是否有任何发布计划？

我在更新时向服务添加了一个新特性(不安全~)和一些新函数。 因此堆内存大小比以前要小一点。

static gattAttribute_t getsetAttrTbl[] =
{
	// 0 GetSet Service
	{
		{ ATT_BT_UUID_SIZE, primaryServiceUUID }, /* type */
		GATT_PERMIT_READ,						  /* permissions */
		0,										  /* handle */
		(uint8 *)&getsetService			 /* pValue */
	},

	// 1 GetSet Characteristic Declaration
	{
		{ ATT_BT_UUID_SIZE, characterUUID },
		GATT_PERMIT_READ,
		0,
		&getsetCharacteristicProperty
	},

	// 2 GetSet Value
	{
		{ ATT_UUID_SIZE, getsetCharUUID },
		0, // This will be set in the GetSet_AUTHEN_Write_Mode()
		0,
		&getsetCharacteristic
	},

	// 3 GetSet Configuration 
	{
		{ ATT_BT_UUID_SIZE, clientCharCfgUUID },
		GATT_PERMIT_READ | GATT_PERMIT_ENCRYPT_WRITE,
		0,
		(uint8 *)&getsetConfig
	},

	// 4 Unsecured Characteristic Declaration
	{
		{ ATT_BT_UUID_SIZE, characterUUID },
		GATT_PERMIT_READ | GATT_PERMIT_WRITE,
		0,
		&getsetCharacteristicProperty
	},

	// 5 Unsecured Characteristic Value
	{
		{ ATT_UUID_SIZE, getsetUnsecCharUUID },
		GATT_PERMIT_READ | GATT_PERMIT_WRITE,
		0,
		(uint8 *) appIdTemp
	},

	// 6 UnsecuredGetSet Configuration 
	{
		{ ATT_BT_UUID_SIZE, clientCharCfgUUID },
		GATT_PERMIT_READ | GATT_PERMIT_WRITE,
		0,
		(uint8 *)&getsetUnsecConfig
	},
};

是否可以确认增加堆内存是否可以降低出现这个问题的可能性？

我已连接智能手机的 HCI 日志。

e2e.ti.com/.../btsnoop_5F00_hci_5F00_202409191159_5F00_old.zip

正常-请参阅机架编号 41855~41860 μ A

异常-请参阅机架编号 40947~40949 (在 cc2640r2f 器件上接收到40949数据包后发生了 HW_FAIL_INGABLE_PKT_LEN)

谢谢！

Calvin

尊敬的 Calvin：

我发现以下 E2E 主题针对您看到的行为提供了一些潜在的缓解选项：

https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1327208/cc2640r2l-l2cap-fragmented-packets-crashes-stack

如果看到仅添加逻辑而不直接影响连接参数或数据包传输的行为、则可以通过修改堆大小来减轻该行为。 另一种选择是缩短连接间隔、如所提供的线程中所述。

此致、

1月

您好、Jan：

我   从 SDK 更改日志的已知问题中找到了 BLESTACK-3934。

但我认为这与我的问题无关、因为数据长度交换 是在问题点作为日志之前执行的。

假设我们产品的先前固件为 V1、添加新特性的固件为 V2。

我检查了这个问题发生了0.06%在 V1和7%在 V2从市场。

1. 我需要知道是否可以通过将 v2的堆存储器增加到 v1来减少这个问题。 如果没有、我需要另一种解决方案。
2. 这是堆栈错误吗？
3. 当发生此断言时,我们的产品被 HAL_SYSTEM_RESET()重置。 如果我不将其复位、会发生什么情况？

谢谢！

Calvin

您好！

在发生 DLE 之后、该行为可能会由于分段而发生、如前面提到的 E2E 主题中所述。 我认为这可能是与票据中描述的错误相同的错误。 如果重新尝试有问题的任何传输、则可能避免在收到错误后复位。 我建议增加堆数量并重新测试、看看行为是否消失。

此致、

1月

您好、Jan：

我们将尝试通过增加堆内存来重现测试。

还有一个问题、

  从堆栈接收 HW_FAIL_INGABLE_PKT_LEN 时、我不想复位系统。

是否有办法正常地仅复位堆栈而不进行系统复位？

谢谢！

Calvin

有任何相关更新？

谢谢！

Calvin

尊敬的 Calvin：

我对延误深表歉意。 我离开办公室了。 您是否能够在增加内存的情况下重现此问题？ 遗憾的是、无法只重置 BLE Stack。 软复位或硬复位最接近。

此致、

1月

该测试会花费很长时间。 我将在获得结果时让您知道。

谢谢！

Calvin