LP-CC2652RB: Network Association fails

Hi Wolfgang,

Are you attempting to create a distributed network?  If so then please make sure that the CC2531 ZNP has BDB_ROUTER_FORM_DISTRIBUTED_NWK_ENABLED defined as one and that you use the SYS_OSAL_NV_WRITE MT command to write ZCD_NV_LOGICAL_TYPE (ID 0x0087) to 0x01 (ZG_DEVICETYPE_ROUTER ).  However, ZB_* are SAPI commands which are only supported in Z-Stack HA 1.2.2a or earlier.  This would mean that you need to set requestNewTrustCenterLinkKey to FALSE in your CC2652RB ZR.  You may need to check the ZNP processing to make sure it allows for Zigbee stack devices to join which are a higher revision than itself.  However, distributed networks are optional in the Zigbee 3.0 Spec and may not be supported in Zigbee HA 1.2 implementations.  Also, Data Requests are a clear sign that the node is acting as a sleepy ZED and not a ZR.  Are the association responses marked as successful or not?  Please provide a full sniffer log file if able.

Edit: in red

Regards,
Ryan

Hi Ryan,

thanks for your reply. 

@BDB_ROUTER_FORM_DISTRIBUTED_NWK_ENABLED 

The BDB_ROUTER_FORM_DISTRIBUTED_NWK_ENABLED flag is defined as one. 

@ZCD_NV_LOGICAL_TYPE

I'm confused about ZCD_NV_LOGICAL_TYPE. Currently, I use 0x01 as I want the CC2531 to act as Router. Am I wrong that 0x02 would set the Type to Enddevice? Being an end device would prevent creating a network, isn't it?

@requestNewTrustCenterLinkKey

I changed the flag to FALSE. But this didn't change the behavior

@DataRequest

In my understanding (see attached sniff) the DataRequest is sent from the CC2652 device to the CC2531. I used the ZR_xxx project for the CC2652. Which device would be the sleepy one in your opinion?

@ association response

Yes, the responses are marked successful (Assoc Status 0x0)

Thanks in advance,

Wolfgang

assoc_failed.zip

You are correct about ZCD_NV_LOGICAL_TYPE, it should be 0x01 for ZG_DEVICETYPE_ROUTER and I apologize for the mistake in my previous reply (now revised).  The Data Requests are coming from the device joining the network so from your previous description they are being sent by the CC2652RB.  What source of CC2531 ZNP are you referencing, and what version of SIMPLELINK-CC13X2-26X2-SDK is being used for the LP-CC2652RB zr_genericapp?  I did not experience any issues in forming & joining a network using two zr_genericapp examples with SIMPLELINK-CC13X2-26X2-SDK v5.20.

Regards,
Ryan

ZCD_NV_LOGICAL_TYPE: Thanks for the clarification

The source of CC2541 ZNP is the one included in Z-Stack 3.0.2, June 15 2018. For the CC2652RB I'm using SimpleLink CC13x2_26x2 SDK 5.20.00.52. 

Kind regards,

Wolfgang

As the CC2531 ZNP is indicating successful association to its open network, I do not suspect any issue present from this device.  The data requests from the CC2652RB is still the most concerning as this was not present in my own test and indicates a ZED node configuration.  Please perform a factory reset by pressing BTN-2 on the LaunchPad before attempting to join the device again.  If this does not work, delete all device memory through CCS debug configurations, Uniflash, or Flash Programmer before re-programming the firmware image.  The last resort is to delete and re-import the zr_genericapp project itself and re-attempt the project build and download.

Regards,
Ryan

Meanwhile, I checked out various options to get a clean device. I've tried all suggested options and experimented with the zc_sw_LP_CC2652RB_tirtos_ccs sample, too. The behavior did not change, unfortunately. I also tried to figure out the origin of the data request. From my understanding, this request is a MAC-message, isn't it?

Am I right,

• that there's no MAC code available to set a breakpoint there? 
• that AF_DataRequest defines the "border" to the code which is not available

Thanks in advance,

Wolfgang

Data Requests are MAC messages, there is no code available in the release SDK as this logic is in the pre-built stack libraries, and AF_DataRequest is a good entry point for the Z-Stack application.

Regards,
Ryan

Meanwhile, I made a new observation. I changed my setup to exclude device and stack differences. I used two CC2652RB Launchpads and (various) samples part of Simplelink.

I'm able to reconstruct the behavior described before: 

• Build coordinator and router project (e.g.  zc_sw and zr_sw)
• Program and run the coordinator
• Program and run the router
• Coordinator: startup network
• Router A: join the network

=> everything works as expected

• Reprogram the coordinator to Router B
• Press Button 1 on Router A to permit join
• Press Button 1 on Router B to join the network

=> now the setup behaves as described in my previous posts. The sniff is absolutely comparable. The inexplicable data request is sent, too. Router B is not connected to the network.

Thanks for your help,

Wolfgang

Router B will not be able to join router A if this node is still associated with the network for which there is no longer a coordinator.  If you would like for either router to form a distributed network then, using zr_genericapp as an example, zclGenericApp_processKey from zcl_genericapp.c must have BDB_COMMISSIONING_MODE_NWK_FORMATION set for (ZG_BUILD_JOINING_TYPE && ZG_DEVICE_JOINING_TYPE).

static void zclGenericApp_processKey(Button_Handle _btn)
{
    zstack_bdbStartCommissioningReq_t zstack_bdbStartCommissioningReq;
    //Button 1
    if(_btn == gLeftButtonHandle)
    {
        if(ZG_BUILD_COORDINATOR_TYPE && ZG_DEVICE_COORDINATOR_TYPE)
        {

            zstack_bdbStartCommissioningReq.commissioning_mode = BDB_COMMISSIONING_MODE_NWK_FORMATION | BDB_COMMISSIONING_MODE_NWK_STEERING | BDB_COMMISSIONING_MODE_FINDING_BINDING;
            Zstackapi_bdbStartCommissioningReq(appServiceTaskId,&zstack_bdbStartCommissioningReq);
        }
        else if (ZG_BUILD_JOINING_TYPE && ZG_DEVICE_JOINING_TYPE)
        {
            zstack_bdbStartCommissioningReq.commissioning_mode = BDB_COMMISSIONING_MODE_NWK_FORMATION | BDB_COMMISSIONING_MODE_NWK_STEERING | BDB_COMMISSIONING_MODE_FINDING_BINDING;  //THIS LINE HAS BEEN CHANGED
            Zstackapi_bdbStartCommissioningReq(appServiceTaskId,&zstack_bdbStartCommissioningReq);
        }
    }
    ...
}

Regards,
Ryan

Did I understand you correctly? The scenario described in my last post should work for the genericapp because there the forming of a distributed network is possible. I think the "else if" part would be responsible for this, isn't  

I've built the zc_genericapp and the zr_generic app and have repeated the steps described before. But the behaviour doesn't change (see sniff).

Kind regards,

Wolfgang

zr_zr_sniff.zip

Your sniffer log shows a joiner device attempting to join router 0xD3A8 which is part of a centralized network that is missing its coordinator.  Hence the Association Response is Successful but then the Update Device and [Tunnel] Transport Key commands never happen since the coordinator does not exist any longer.  Therefore the 0xD3A8 router needs to be factory reset and configured to form a distributed network (no coordinator trust center) in order for another router to join it.

Regards,
Ryan

Thanks for your reply. I added BDB_COMMISSIONING_MODE_NWK_FORMATION flag for routers and it seems that the CC2652 setup running zr_generic app works.

Therefore I continued using the original setup CC2530 connected to Z-Tool and one CC2652. A comparison of the sniff suggests that the CC2530 assumes to be part of a  centralized. security network. My idea was disabling security completely, therefore. But this seems to be impossible according to the Z-Stack User Guide, is it?  If so, does this mean that Z-Stack 3.0.x devices are unable to communicate with older devices running ZStack-EXP5438-2.5.1. At least I have not found a Z-Stack 3.x. for devices using MSP430F5437A, CC2520, CC2591). 

Thanks for your support,

Wolfgang 

Zigbee 3.0 is backwards compatible with Z-Stack HA 1.2 if TC Link Keys are enabled (i.e. requestNewTrustCenterLinkKey = FALSE) but distributed networks are not supported prior to Zigbee 3.0.  Removing ZSTACK_SECURITY would break Z-Stack operation.  Nevertheless, other E2E threads indicate that compatibility may be possible.

Regards,
Ryan