CC2530 - newer finishes Commisioning in Power Saving mode

I would suggest you to use sniffer to check what exactly happens over the air.

Hi YiKai

Thank you for your response.

I will try to get a sniffer up and running. Stay tuned! 

Hi YiKai

I have now purchased a CC2531 USB Dongle as sniffer. And plan to use Wireshark.
Unfortunately, the delivery will take about 3 weeks.

For how long time will this thread be open without activity? Will it be closed automatically within the 3-4 weeks?
If yes - do I 'just' have to place a comment once in a while to keep it alive?

Hi Flemming,

As it appears that the device has joined and connected properly, it is possible that the sleepy ZED is operating as intended but the ZC Zigbee2MQTT is not expecting to communicate with a polling device.  If the interview process communicates through broadcast messages or direct messages without waiting for Data Requests from the ZED, then communication will fail.  This may have been avoided during device joining since several messages are so quite consecutively, but then does slow down after the ZED has fully joined and reduced its poll rate.  You can review the Z-Stack 3.0.2\Documents\CC2530\Power Management For The CC2530.pdf documentation and contact the zigbee2mqtt team for additional thoughts (I'm aware that Koen Kanters has involvement and is sometimes active on the E2E).

E2E threads are automatically closed after four weeks of inactivity (i.e. no new replies).

Regards,
Ryan

Hi Ryan

Thank you for your feedback!

This actually makes good sense. I looked through the Power Management document as you suggested, and it gave me some ideas to work with first.

If that fails I will try to reach out to the Zigbee2MQTT team to get their point of view.

Best regards

Flemming

Hi Ryan

As mentioned, I wanted to conduct some more tests before reaching out to the Zigbee2MQTT team. I aim to gather as much information as possible for them.

I planned to test what would happen if the device was configured correctly as a sleeping device but never actually entered sleep mode. The idea was to see if the power-down somehow impacted the Commissioning communication with Zigbee2MQTT, as if the device was simply shutting down during the Commissioning process.

The way I tested it was by forcing the device not to enter sleep mode, achieved by commenting out 'osal_pwrmgr_powerconserve()' in OSAL.c.

OSAL.c

#if defined( POWER_SAVING ) && !defined(USE_ICALL)
  else  // Complete pass through all task events with no activity?
  {
    //osal_pwrmgr_powerconserve();  // Put the processor/system into sleep
  }

Now the device does not enter sleep mode, but the problem with Commissioning still persists.

Does this behavior change your view of your suggestion regarding the poll rate?

The commissioning process is assumed to be successful and completed given that device_joined and device_completed are shown on the ZC Zigbee2MQTT log.  Since your workaround has not been tested internally by TI, you would need to verify that the device_interview and pairing messages are being received and processed by the ZED.  This can be accomplished through a sniffer log comparison or by further debugging incoming messages through zcl_ProcessMessageMSG.  

Regards,
Ryan

OK - thanks.

I will wait for the sniffer to arrive. Anything else now will just be guess work.

While I wait for the sniffer... I looked into zcl_ProcessMessageMSG as you suggested, to see if I could figure something out in the meantime.
And the thing is, I actually got it to work!

The device starts the commissioning, and I get these responses AF_INCOMING_MSG_CMD / ZCL_PROC_SUCCESS during the process, and the device then goes to sleep. Big success!

For now I just use these conservative settings:
-DRFD_RCVC_ALWAYS_ON=FALSE
-DPOLL_RATE=1000
-DQUEUED_POLL_RATE=100
-DRESPONSE_POLL_RATE=100
-DREJOIN_POLL_RATE=440

But this is working in debug mode only. When I create the HEX file and upload it to the device, it does not work. The device starts the commissioning, but there is no AF_INCOMING_MSG_CMD / ZCL_PROC_SUCCESS responses (I made some checks with LED's).

What could cause this different behavior between debug mode and programming the chip? Any suggestions on what to look for?

I appreciate the update.  Does your CC2530 device have a working, reliable external LF crystal attached?  This may be necessary for low-power standby operation, and without it the device fails when attempting to enter a sleep state.  The difference with debug mode could be that the JTAG forces the device to stay active, thus it continues to operate as before.

Also, would you consider upgrading to the CC2652RX or other similar device on the SIMPLELINK-LOWPOWER-SDK?  This would give you the latest and most reliable Z-Stack solutions which are capable of accomplishing far more than the CC2530.

Regards,
Ryan

Thanks for swift reply.

Unfortunately, at the moment, an alternative to CC2530 like the CC2652RX is not an option.

Crystal:
The device is based on the E18-MS1-PCB module from EBYTE. This module is well-known and can enter sleep mode in other applications. So, I do not
suspect the crystal to be the problem. That would be highly unlikely with this well-proven module.

JTAG: (I debug using the 'CC Debugger')
I am not quite sure what you mean. Do you mean it's forced to stay active during the commissioning only? Because the device actually enters sleep mode after successfull commissioning using the 'CC Debugger'. I can see that from the LED turning off and the reduced power consumption. Something else must be going on.

Have you tested on multiple EBYTE modules?  It may be possible that the crystal is failing on this specific board, perhaps even due to outside factors such as ESD or over-voltage situations.  Also, do you have any method, through user interface (it appears you may have an accessible LED) or Zigbee messages, to confirm that the CC2530 device is still actively  processing application and network information as compared to being trapped in a HAL assert or frozen?  It would also be helpful to further evaluate device behavior if the ZED is connected to a TI ZC, such as SampleLight or a ZNP + Z-Tool, to compare behavior.

Regards,
Ryan