CC2640R2F: HW_FAIL_INADEQUATE_PKT_LEN occurred after a

Part Number: CC2640R2F

Tool/software:

Hello,

I'm using simplelink_cc2640r2_sdk_5_30_00_03 and blestack not ble5stack for our peripheral product.

I updated firmware of our product and then HW_FAIL_INADEQUATE_PKT_LEN occurred in the market.

I think this issue is same with the referenced thread and it's not fixed on the cc2640r2_sdk. Is it right? Is there any release plan for the patched sdk?

I added a new characteristic(unsecured ~) on a service and some new functions on the updating. So the heap memory size is little bit smaller than before.

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
	},
};

Could you confirm if increasing the heap memory can reduce the probability of occurrence of this problem?

I attached hci log of the smartphone.

btsnoop_hci_202409191159_old.zip

normal - refer to frame no. 41855~41860

abnormal - refer to frame no. 40947~40949 (HW_FAIL_INADEQUATE_PKT_LEN occurred after received 40949 packet on the cc2640r2f device)

Thanks,

Calvin

Hi Calvin,

I have found the following E2E thread that provides some potential mitigation options for the behavior you are seeing:

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

If you are seeing the behavior exclusively adding logic that does not directly impact connection parameters or packet transmissions, then you may be able to mitigate the behavior by modifying the heap sizes. Another option would be to reduce the connection interval as mentioned in the provided thread.

Best Regards,

Jan

Hi Jan,

I found the BLESTACK-3934 from the known issue of the sdk changelog.

But I think it's not related to my issue because the data length exchange executed before the problem point as the log.

Let's assume the prior firmware of our product is V1 and the firmware added a new characteristic is V2.

I checked the issue occurred 0.06% on the V1 and 7% on the V2 from the market.

1. I need to know if this problem can be reduced by increasing the heap memory of v2 as much as v1. If not, I need another solution.
2. Is this a stack bug?
3. Our product is reset by HAL_SYSTEM_RESET() when this assert occurred. What happens if I don't reset it?

Thanks,

Calvin

Hi,

It is possible for the behavior to occur due to fragmentation after the DLE occurs as mentioned in the previously mentioned E2E thread. I think it is likely to be the same bug as the one described in the ticket. It may be possible to avoid resetting after getting the error provided any transmission that had the issue is re-attempted. I would suggest increasing the heap and retesting to see if the behavior goes away.

Best Regards,

Jan

Hi Jan,

We will try reproduce test by increasing the heap memory.

One more question,

I don't want to reset system when receive the HW_FAIL_INADEQUATE_PKT_LEN from the stack.

Is there a way to gracefully reset just the stack without doing system reset?

Thanks,

Calvin

Any update on this?

Thanks,

Calvin

Hi Calvin,

My apologies for the delay. I was out of office. Were you able to reproduce the issue with increased memory? Unfortunately, it is not possible to only reset the BLE Stack. A soft or hard reset would be the closest thing.

Best Regards,

Jan

The test will take quite some time. I'll let you know when I get the results.

Thanks,

Calvin

Hi Calvin,

Understood, I will keep the thread open for now. Once you have a chance to run the test, then let me know what results are observed and we will continue to work on this together.

Best Regards,

Jan