cancel
Showing results for 
Search instead for 
Did you mean: 

NVM saving persistent data

ISLTG
Associate III

Hello,

I copied the logic from the NVM Zigbee examples. 

I notice that the end devices almost periodically calls the persistent data callback to save when I am sending sequential data sequences.

However, this unfortunately causes the end device to sometimes miss the reception of Zigbee data, and in my case, does not call ZbZcl_custom_ls_ServerSendCommandRsp.

The devices end up LOSING connection shortly after saving to persistent data.

Is this intended, and are there any solutions?

Thanks,

11 REPLIES 11
Ouadi
ST Employee

Hello @ISLTG,

Thanks for contacting us.

To better understand your issue, I have some questions :

What is the configuration used for both devices ? End device and coordinator ( sleep mode, persistable attributes implemented..)

When you say the device is loosing connection, do you detect a Parent Link Failure ? If yes, this means that the end device does not receive a response to its end device timeout request from the parent, what is the end device timeout configuration ?

Have you calculated the amount of time during a persistant data notification ? 

Also a full logs and Wireshark capture would be appreciated. 

Thanks & best regards,

Ouadi

 

ISLTG
Associate III

Hello @Ouadi ,

Thank you very much for your response!

The end device is not on sleep mode, and I am not explicitly saving anything more than that from the example NVM code. On the coordinator, I do send binding requests and recover this information on startup.

I just tested and it does sometimes detect a parent link failure, but the connection tends to stay as it still receives information after and acts normally. When all devices stop responding, this typically happens when they all save to persistent data around the same time. Coordinator callback enters with ZCL_STATUS_FAILURE. How can I find the end device timeout configuration?

Sometimes the coordinator and end device take a couple seconds to save to persistent data.This also sometimes causes the coordinator to enter the NMI handler, and I have to delete NVM data for the device to exit the handler on reboot.

Please let me know if anything else is needed.

Hello,

Thanks for these informations. 

Still need some clarifications on how the coordinator sends data ana manages the response. Are you using Unicast or broadcast mode ?

End device timeout is set using ZbStartupT struct => config.endDeviceTimeout

Please share the logs and Wireshark when the issue occurs.

Best regards,

Ouadi

ISLTG
Associate III

Hello @Ouadi,

1) I am using Unicast as I found broadcast mode to be very unreliable even with only 1 device. I am sending data via: 

ZbZclSet_custom_ls_ClientCommand(zigbee_app_info.custom_ls_client, &dst,data, data_len, custom_ls_client_cb, NULL)

where the function is only slightly changed.

2) config.endDeviceTimeout = 0xFF in APP_ZIGBEE_NwkForm.

3) I apologize but I am not familiar with Wireshark or sniffing in general. Are there any resources you can point me to if this is needed?

Thanks,

Ouadi
ST Employee

Hello @ISLTG,

For this use case the broadcast mode is more suitable and it should work properly.

You say that you have troubles when using broadcast even with 1 device, Are you using a custom boards or Nucleo ? Otherwise it may be linked to your code.

I recommend also to wait for the callback custom_ls_client_cb before sending a new data, this allow to manage properly the responses with a retry mechanism by the stack.  

For sniffer part, please refer to the wiki page below that explain how to configure sniffer for 802.15.4 => https://wiki.st.com/stm32mcu/wiki/Connectivity:How_to_configure_sniffer_for_802.15.4 

Regards,

Ouadi

 

ISLTG
Associate III

Hello @Ouadi,

I am using the USB Dongles (P-NUCLEO-WB55) as the end devices and Nucleo board (NUCLEO-WB55RG) as the coordinator. I will try to first transition to broadcast logic.

With broadcast mode, I have a couple questions and comments. 

1) How does the callback work in broadcast mode in regards to multiple devices responses, considering ZCL_STATUS_TIMEOUT and ZCL_STATUS_FAILURE.

2) Must I wait until all devices respond/timeout to send the next broadcast?

Thanks,

ISLTG
Associate III

[ DELETED ]

Hi @ISLTG,

Broadcast communication in Zigbee uses a passive acknowledgement, meaning that when the message is sent it will be repeated by the neighboring with router capability ( Coordinator/ routers), in your case, end devices receiving a broadcast message will not send an acknowledgement, only responses if configured at the app level. 

The callback will be triggered as many time as responses, no error will be detected as there will be no ack.

For broadcast mode, depending on your time contraints, you can send broadcast with a configured timer with no condition on the responses.

Here is an example of the implementation :

 struct ZbApsAddrT dst;

  memset(&dst, 0, sizeof(dst));
  dst.mode = ZB_APSDE_ADDRMODE_SHORT;
  dst.endpoint = SW1_ENDPOINT;
  dst.nwkAddr = 0xFF; /* For broadcast */
 
  if (ZbZclSet_custom_ls_ClientCommand(zigbee_app_info.custom_ls_client,
                                       &dst,message, custom_ls_client_cb, NULL) != ZCL_STATUS_SUCCESS)
                {
                   APP_DBG("Error, ZbZclSet_custom_ls_ClientCommand failed (SW1_ENDPOINT)");
                }  

Best regards,

Ouadi

ISLTG
Associate III

Hello @Ouadi,

Thanks for the response! I apologize for all the questions. But I have some last quick questions:

1) Do you know the minimum time interval between broadcasts?

2) What is the difference between the broadcast code you sent and the one below in terms of functionality? 

  memset(&dst, 0, sizeof(dst));
  dst.mode = ZB_APSDE_ADDRMODE_GROUP;
  dst.endpoint = SW1_ENDPOINT;
  dst.nwkAddr = SW1_GROUP_ADDR;

 I really appreciate the help! Thanks,