Zigbee end device hardly wake up from the STOP2 mode.

[Phang]

Hi, 

I have 2 questions here for help.

1.)

We encountered 2 x AAA batteries drained out very fast problem feedback by our customer. In order to resolve this problem I enabled STOP2 mode and added in the following 2 lines of codes in function “APP_Zigbee_NwkForm()” which following exactly the sample project did (Zigbee_OnOff_Client_SED). As the result I can see the battery consumption dropped significantly from mA to uA. However, during the functional test, noticed the device always encountered hardly wake up from the STOP2 mode after multiples times of button pressing action. I cannot find much information about these 2 lines of codes therefore request ST’s expertise to help up. Our production line has stop and waiting for my firmware update in order to resume. 

 

/* Add End device configuration */

config.capability &= ~(MCP_ASSOC_CAP_RXONIDLE | MCP_ASSOC_CAP_DEV_TYPE | MCP_ASSOC_CAP_ALT_COORD);

config.endDeviceTimeout=ZED_SLEEP_TIME_30S;

 

 

 2.)

I noticed that, after added in these 2 lines of code (as shown above), the output from the button pressing (ON/OFF) always stop at 37th press. If I continue the pressing, the output is started lagging, and eventually no output at all until I reset the MCU. 

 

[Ouadi]

Hi ​@Phang

Please find below the answers :

1. The 2 added lines configure the product as a Sleepy End Device (SED).
   Specifically, MCP_ASSOC_CAP_RXONIDLE is cleared so the Zigbee receiver is not always on when idle, which is why current consumption drops significantly.
   config.endDeviceTimeout = ZED_SLEEP_TIME_30S; sets the parent timeout for the sleepy device.

   However, these settings alone are not sufficient to guarantee stable STOP2 operation. In addition to SED configuration, the application must also correctly handle STOP2 wake-up source configuration, GPIO/EXTI button wake-up, clock/timer restoration after wake-up, and Zigbee polling/resume behavior.

   Based on the symptom, the issue is likely related to STOP2 wake-up handling or low-power integration, rather than these 2 lines themselves.

   In short: the current reduction is expected, but the wake-up instability indicates that the full sleepy-end-device low-power implementation is not yet completely integrated.

2. The issue after 37h has been identified internally and fixed in the release version v1.24, please upgrade the firmware to the latest version.

Kind regards,

Ouadi

[Phang]

Hi Ouadi,

1. Yes, you are right. Understand from the SED sample code readme.txt, in order to reached ultra low power consumption, it is needed to use RFD wireless stack on client side and hence the 2 lines of code to take effect. So I followed and flashed the RFD stack into our board. However, this action create another problem where the client cannot/fail to pair with the sever which use FFD wireless stack. As shown below debug picture. Any idea what is wrong? Any suggestion? 

   

2. What do you mean by “fixed in the release version v1.10”? Can you shared the details and link if any? Thanks

[Ouadi]

Hi ​@Phang,

1. Have you done a full chip erase on both boards before trying a new commissioning ? Can you give it a try ? 
2. Please use the latest version of Cube firmware v1.24

Regards,

Ouadi

 

[Phang]

Hi Ouadi,

 

1. Yes, I did it but doesn’t help. By the way, I manage to resolve the hang at “Init_ZigbeeStack_Infrastructure” mentioned in my earlier post. After I removed others 6 OnOff client clusters and it move on to do the pairing with the server (Dongle with FFD wireless stack). However, the server cannot receive and output the signal/data from the client router which I’m not sure why. Attached is the debug message  text file. Can you help to interpret the output messages and find out why the client OnOff router cannot transmit signal/data after paired with the server. Thanks.
2. What is the fixes in “Cube firmware v1.24” especially for the OnOff client router / SED with RFD wireless stack? 

[Ouadi]

Hello ​@Phang,

Thank you for sharing the log file.

1. At this stage, the logs do not appear to contain enough detailed information about the Zigbee communication flow itself. They mainly show the commissioning process, but they do not provide sufficient visibility into the actual transmission path for the OnOff client.

Could you please:

• enable more detailed logs
• set the logging level to ALL
• share the relevant part of your Zigbee transmission implementation, especially where the OnOff command or data is sent

This would help us better understand whether the issue.

2. Regarding Cube firmware v1.24, there were indeed some fixes and improvements in the Zigbee stack, but there does not appear to be any fix specifically targeting the OnOff cluster

Kind regards,

Ouadi