Compiler/CC2538: ZigBee 删除组失败问题

Please post your question in English.

Siri

OK,Siri:

Recently, I was doing an experiment. A centralized control brought several devices into the network. Some ZRs and ZEDs were all connected to a single light. All were added to a group. At the beginning, a switch command was issued to members of the group through multicast, all ok, However, after the power was turned off, multicasting again found that the ZED lamp could be controlled, and the ZR lamp did not respond. By capturing packets, ZR played a forwarding role, but ZR itself did not respond to the command to control the light, but only forwarded the multicast News, unicast this ZR can control the lights. Later, the ZR group of this problem was deleted by command execution, but the return was ZCL_STATUS_NOT_FOUND [0x8b], and the deletion group called uint8 aps_RemoveGroup (uint8 endpoint, uint16 groupID) API, but we ca n’t see the specific implementation here. Our temporary solution is to delete the problem device, then restore the factory settings and re-enter the network to add the group, and then it is normal again, but it is not guaranteed that every subsequent one will be ok. See luck, and the previous situation will appear later. I don't know if this is a bug in Z-STACK3.0.2, is there any good solution?

Try to use aps_FindGroup to check if the device still has group settings when you see this issue.

Hi Mike&Hu,

There is an issue where ZCL group IDs are written to/restored from NV incorrectly: https://e2e.ti.com/support/wireless-connectivity/zigbee-and-thread/f/158/t/845952 

I recommend that you try applying this fix from the v3.30 SIMPLELINK-CC13X2-26X2-SDK to Z-Stack 3.0.2 and let us know if it resolves the behavior.

Regards,
Ryan

ok,I will check.but if the result is not found,what it means?if the result is found,and what it means?

thank you,Ryan,I will be check it,if worked,I will tell the result right here.

That's not resolves the behavior, and instead of solving problems, it causes new problems. when operate broadcast,ZC multicast is actually unicast.

Ryan, because I do n’t know the detailed process of adding a group (this part of the code is not public), I guess there are two kinds of problems that may cause 0x8b. One possibility is that when the group is added for the first time, it is only stored in the apsGroupTable variable, but not Success or no write to NV; The second possibility is that the first time the group is added successfully and it is also successfully written to the NV. After the device is powered off and restarted, the group information in the NV needs to be restored (the repair method in the connection above) appears problem.

So I do n’t know if you can provide some of these non-public code segments to the maximum or tell me the internal execution process (such as which APIs to call) during the process of adding and deleting group.

When adding a group, is it necessary to write NV and apsGroupTable at the same time, is it necessary to read the group information from the NV first and then write it to the apsGroupTable for recovery after power off and restart?

OsalPort_memcpy((uint8 *)buf + (uint16)((sizeof(uint16)) + (i * sizeof ( struct apsGroupNVItem ))),  &item, sizeof ( struct apsGroupNVItem ));

And why add "(uint16)((sizeof(uint16))"  but not "(uint32)((sizeof(uint32))" ?

// APS Layer NV item IDs
#define ZCD_NV_BINDING_TABLE              0x0041
#define ZCD_NV_GROUP_TABLE                0x0042 // only one byte size
#define ZCD_NV_APS_FRAME_RETRIES          0x0043

Hi,Ryan,

I checked the first address of the NV storage group table（0x0042）, which is only one byte in size from the next entry(0x0043). At most, only one group number can be saved, not a structure. However, the entire structure is stored in the apsGroupTable group linked list. Where is the content of this apsGroupTable obtained after power off and restart?

when I delete a device's group(like 7) from ZC,the device back a status not found[0x8b], and then I  add the device to a same group(like 7),but the device back DUPLICATE_EXISTS [0x8a],according to the Z-STACK API,aps_AddGroup and aps_RemoveGroup update the group table fisrt and if NV_RESTORE defined then update NV.That's means the problem may caused by the group table.That's all my guess,Can you give me some suggestions?

Can anyone answer? It is easy to reproduce, one ZC with two ZRs and one ZED, add to the same group, wait for ten minutes after power off, then delete the groups one by one, try again you will find it. 

YK, that's not found ,too

Can any TI experts answer it ? This is a very serious problem !!! 

Hello Mike,

I've sent you a friend request, upon accepting I will reach out to you through a private message to resolve the issue.

Regards,
Ryan

thank you,Ryan.

I accept,but it access dennied this afternoon ,so I write here 

I tried a method today,when ZR receive a group add command,I add the follow codes to zclGeneral_AddGroup and intend to back up the ZR group info,

static ZStatus_t zclGeneral_AddGroup( uint8 endPoint, aps_Group_t *group, uint8 *pData )
{
  uint8 nameLen;
  uint8 nameSupport = FALSE;
  ZStatus_t addSts = FAILURE;

  pData += 2;   // Move past group ID
  nameLen = *pData++;

  // Retrieve Name Support attribute
  zcl_ReadAttrData( endPoint, ZCL_CLUSTER_ID_GEN_GROUPS,
                    ATTRID_GROUP_NAME_SUPPORT, &nameSupport, NULL );
  
  if ( nameSupport )
  {
    if ( nameLen > (APS_GROUP_NAME_LEN-1) )
       nameLen = (APS_GROUP_NAME_LEN-1);
    group->name[0] = nameLen;

    zcl_memcpy( &(group->name[1]), pData, nameLen );
  }
  addSts = aps_AddGroup( endPoint, group );
  

	// add by mike
	#if ( (ZSTACK_DEVICE_BUILD == DEVICE_BUILD_ROUTER) )
	if(!osal_nv_item_init(ZCD_NV_GROUP_TABLE_BP, (sizeof(apsGroupItem_t)), NULL))
	{
	
		apsGroupItem_t store;
		store.next = NULL; // if store itself group info
		store.endpoint = endPoint;
		store.group.ID = BUILD_UINT16( pData[0], pData[1] );
		store.group.name[0] = nameLen;
		zcl_memcpy( &(store.group.name[1]), pData, nameLen );
		
		osal_nv_write(ZCD_NV_GROUP_TABLE_BP, 0, (sizeof(apsGroupItem_t)), &store);
	}
	#endif
	// end add
	
  return addSts;//( aps_AddGroup( endPoint, group ) );
}

when system start,I add the follow codes to ZDOInitDeviceEx before NLME_SetBroadcastFilter,and intend to restore ZR group info if the group is missing,

#include "aps_groups.h"
#if ( (ZSTACK_DEVICE_BUILD == DEVICE_BUILD_ROUTER) )
  ZStatus_t sts ;

  apsGroupItem_t *apsGrouptable;
  apsGrouptable = osal_mem_alloc( sizeof( apsGroupItem_t )  );
	
	if(apsGrouptable)
	{
		if(osal_nv_item_init(ZCD_NV_GROUP_TABLE_BP, (sizeof(apsGroupItem_t) ), NULL) == SUCCESS)
		{	
			osal_nv_read(ZCD_NV_GROUP_TABLE_BP, sizeof(apsGroupItem_t), (sizeof(apsGroupItem_t)), apsGrouptable);
			if(apsGrouptable->endpoint && apsGrouptable->group.ID)
			{
				if(aps_FindGroup(apsGrouptable->endpoint, apsGrouptable->group.ID) != SUCCESS)
				{
					aps_RemoveAllGroup(apsGrouptable->endpoint);
					sts = aps_AddGroup(apsGrouptable->endpoint, &apsGrouptable->group);
				}
			}
			
		}		

		osal_mem_free(apsGrouptable);
  }
  #endif

aps_RemoveGroup can't remove group info,it returned 0x8b,so I use aps_RemoveAllGroup,custom define ZCD_NV_GROUP_TABLE_BP 0x0F0B

But it already not resolved the issue,so bad.

With the help of Ryan, I located the problem. When writing the group information to NV (osal_nv_write), there will be random problems. I also tested it. When writing data to a custom NV ITEM, it will also happen. The probability of entering the error.

Does Ryan provide solution? If yes, can you share it here to benefit others having similar issue?

I sent him a message last night, but there is no reply at the moment. I will definitely share it if there is a solution. By the way, look at this link：

e2e.ti.com/.../910089

Is it possible that this is related to power stability of your device?

Because my device needs to be connected to a 100-watt LED lamp, it is not powered by a battery, and it is connected to 220V mains input, so the probability of unstable power supply should not be large.

I would like to suggest you to verify this first. Can you try to use power supply to power your CC2538 custom board to do the same test and see if this issue can be reproduced?

Well, I can try it. I also looked at the similar osal_nv_write problem mentioned by some people on E2E before, but in the end it was gone, and there were few replies.

Usually, the NV write issue is caused by power problem so please check it first.

YK,

So far no solution has been found that can be shared. 

Mike&Hu,

We should continue this conversation on the other E2E post if the problem has migrated to a NV issue.

Regards,
Ryan

@Ryan have you confirmed this is an issue caused by NV write failed?

YK,

I have not confirmed the behavior reported by Mike&Hu's investigation.

Regards,
Ryan

OK, maybe this is a specific issue of NV write that only happens on Mike’s CC2538 custom board...