STM32WB5MMG Zigbee Random Disconnection and reJoin not working

[Jonny]

Hi All,

I'm currently using an STM32WB5MMG module on two devices to establish a Zigbee connection between them.

My project is based on the example called "BLE_Zigbee_Dyn"(one device should also be able t communicate using BLE ) implementing everything over an RTOS environment.

On Zigbee network One works as a Coordinator and the other is the end device;

Both are configured to have two endpoint : one Switch endpoint (to manage a toogle and a polling system ) and one Level Endpoint (to Manage the behaviour of the coordinator device)

Below the code for the configuration of the two endpoints

static void APP_ZIGBEE_ConfigEndpoints(void)
{
  struct ZbApsmeAddEndpointReqT req;
  struct ZbApsmeAddEndpointConfT conf;
 
  memset(&req, 0, sizeof(req));
  req.profileId = ZCL_PROFILE_HOME_AUTOMATION;
  req.deviceId = ZCL_DEVICE_ONOFF_SWITCH;
 
  /* Endpoint: SW1_ENDPOINT */
  req.endpoint = SW1_ENDPOINT;
  ZbZclAddEndpoint(zigbee_app_info.zb, &req, &conf);
  //assert(conf.status == ZB_STATUS_SUCCESS);
 
  /* OnOff Client */
  zigbee_app_info.onoff_client_1 = ZbZclOnOffClientAlloc(zigbee_app_info.zb, SW1_ENDPOINT);
  assert(zigbee_app_info.onoff_client_1 != NULL);
  ZbZclClusterEndpointRegister(zigbee_app_info.onoff_client_1);
 
  memset(&req, 0, sizeof(req));
  req.profileId = ZCL_PROFILE_HOME_AUTOMATION;
  req.deviceId = ZCL_DEVICE_ONOFF_SWITCH;
 
  /* Endpoint: SW2_ENDPOINT */
  req.endpoint = SW2_ENDPOINT;
  ZbZclAddEndpoint(zigbee_app_info.zb, &req, &conf);
  //assert(conf.status == ZB_STATUS_SUCCESS);
 
  /* OnOff Client */
  zigbee_app_info.onoff_client_2 = ZbZclOnOffClientAlloc(zigbee_app_info.zb, SW2_ENDPOINT);
  assert(zigbee_app_info.onoff_client_2 != NULL);
  ZbZclClusterEndpointRegister(zigbee_app_info.onoff_client_2);
 
  
 
} /* config_endpoints */
 
 
static void APP_ZIGBEE_ConfigEndPoints_Level(void)
{
 
	struct ZbApsmeAddEndpointReqT req;
	struct ZbApsmeAddEndpointConfT conf;
 
	memset(&req, 0, sizeof(req));
	req.profileId = ZCL_PROFILE_HOME_AUTOMATION;
	req.deviceId = ZCL_DEVICE_LEVEL_SWITCH;
 
	/* Endpoint: LEVEL_ENDPOINT */
	req.endpoint = LEVEL_ENDPOINT;
	ZbZclAddEndpoint(zigbee_app_info.zb, &req, &conf);
	//assert(conf.status == ZB_STATUS_SUCCESS);
 
	/* Level Client */
	zigbee_app_info.level_client = ZbZclLevelClientAlloc(zigbee_app_info.zb, LEVEL_ENDPOINT);
	assert(zigbee_app_info.level_client != NULL);
	ZbZclClusterEndpointRegister(zigbee_app_info.level_client);
 
 
 
}

What I do on the coordinator side is to send, with an interval of 1 second, a polling signal using the Switch Endpoint and a "behaviour signal" using the Level Endpoint.

To do that I create two timers with an interval of 1 second; using RTOS mutex I also avoid having multiple commands on HCI that could cause problems.

I also implemented a check to have at least 500 ms between the transmission of the two types of endpoint.

I can establish the communication without any issue; the only problem is that after around 20 minutes the connection just drops (I can see this because I have a fail in the callback of the switch endpoint that manage the polling system) .

When this happens the end device try to reconnect to the coordinator.

In the rejoining procedure I first use the ZbReset function to reset the Zigbee connection and then I reInit the Zigbee Stack (the ReInit function is basically the same of APP_ZIGBEE_StackLayersInit without the ZbInit function in it).

If I try to simulate a disconnection, removing the battery from the coordinator device, I can clearly see that after reconnecting the battery the system is able to reconnect to the coordinator without any issue.

But If the disconnection happens spontaneously after 20 minutes, even if all the reinit procedure complete successfully, when the functionZbStartupWait(zigbee_app_info.zb, &config); is executed it now takes something around 2 -3 minutes to exit (the task is suspended till I don't receive the callback) and the end device cant find nor join the network anymore.

If I disconnect the battery on the coordinator device nothing happens (so i Suppose the problem is not server-side) ; if I disconnect and reconnect the battery on the end device the system actually starts to work again (till the next disconnection event).

Does anyone know what could lead to this behavior of the startup procedure?

The other problem is also why this random disconnection event happens at all but for now I would like to avoid at least the startup function to remain stuck for ages apparently for no reason at all

Best Regards

Jonny

[Remi QUINTIN]

We detected an issue with the dynamic mode (Zigbee/ble). This issue will be solved in the next WB FW package v 1.13. But it is linked to the low power mode which may not the case here.

Can you clarify what you call disconnection => Is it a LED that is not toggling any more?

[Jonny]

Hi Remi,

In the condition I was talking in the post honestly I was not using LP mode in either of the two devices.

Right now we are also working on a project that instead uses BLE mesh and one of the devices is a Low Power Node; so your answer probably could be related to the problem we have there.

The problems we are facing in the case of the BLE Mesh are

1) With the Proxy node there is no way to go on standby mode because every time that I try to wake up from STOP MODE (STOP MODE 2 in my case) the mesh network simply doesn't work properly

You will find all the details on this post

https://community.st.com/s/question/0D53W00001BwdDaSAJ/stm32wb-ble-mesh-and-stop-modehow-to-stop-rf-activity-

2) The Low power Node works properly and It enters and exits the STOP MODE 2 without any issue, reestablishing the connection with the proxy node correctly; the problem is that sometimes I found that the node is stuck into the function

HW_AES_WaitComplete()

I found out that this function is related to the library function

  BLEMesh_Process();

But I don't have the source code so I can't analyze it more deeply

I know that my question here is related to Zigbee but honestly I'm not receiving any answer from your support and at least I would like to know If this problem with BLE could be due to this bug you detected