This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC1352P: FFD trying to join network as a RFD

Part Number: CC1352P
Other Parts Discussed in Thread: SYSCONFIG, Z-STACK, CC2430, SIMPLELINK-CC13X2-26X2-SDK

We've recently ported our application to SDK3.30 and are now seeing several new strange behaviors.  This is one of them.

Per the attached wire shark capture, you can see a device sending out beacon requests and then it sends an association request, but its asking to associated as a RFD.  (See frames 21 - 27)

Our device resets if it associates as the wrong type of device and then tries again.

Eventually it sends an association request as an FFD and then completes the completes the key exchange and runs normally. (See frames 256 - 295)

This was not occurring with the SDK3.20 stack.

Did something change in the way the BDB needs to be set up?

Our device can be either a Coordinator OR Router. 

// define to include both coordinator and router capabilities
#define ZSTACK_DEVICE_BUILD (DEVICE_BUILD_COORDINATOR | DEVICE_BUILD_ROUTER)

 In the following code, we first make a call to set up the default bdb parameters (MyApp_initParameters)

Then once we know what device type we are (Coordinator or Router) and a user specified PAN_ID,  we call MyApp_SetPanId() which calls Zstackapi_bdbStartCommissioningReq() with the desired commissioning_mode.

This is when it starts sending Beacon Requests and for some reason associating as a RFD as demonstrated in the wireshark capture.

Any thought on why this is occurring would be appreciated.

- Bill

 
static void MyApp_initParameters( void )
{
  zstack_bdbSetAttributesReq_t zstack_bdbSetAttrReq = {0};

  zstack_bdbSetAttrReq.has_bdbCommissioningGroupID          = TRUE;
  zstack_bdbSetAttrReq.bdbCommissioningGroupID              = BDB_DEFAULT_COMMISSIONING_GROUP_ID;

  zstack_bdbSetAttrReq.has_bdbPrimaryChannelSet             = TRUE;
  zstack_bdbSetAttrReq.bdbPrimaryChannelSet                 = BDB_DEFAULT_PRIMARY_CHANNEL_SET;

  zstack_bdbSetAttrReq.has_bdbScanDuration                  = TRUE;
  zstack_bdbSetAttrReq.bdbScanDuration                      = BDB_DEFAULT_SCAN_DURATION;

  if ( isCoordinatorMode() )
  {
    zstack_bdbSetAttrReq.has_bdbJoinUsesInstallCodeKey        = TRUE;
    zstack_bdbSetAttrReq.bdbJoinUsesInstallCodeKey            = BDB_DEFAULT_JOIN_USES_INSTALL_CODE_KEY;

    zstack_bdbSetAttrReq.has_bdbTrustCenterNodeJoinTimeout    = TRUE;
    zstack_bdbSetAttrReq.bdbTrustCenterNodeJoinTimeout        = BDB_DEFAULT_TC_NODE_JOIN_TIMEOUT;

    zstack_bdbSetAttrReq.has_bdbTrustCenterRequireKeyExchange = TRUE;
    zstack_bdbSetAttrReq.bdbTrustCenterRequireKeyExchange     = BDB_DEFAULT_TC_REQUIRE_KEY_EXCHANGE;

    zstack_bdbSetAttrReq.has_bdbSecondaryChannelSet           = TRUE;
    zstack_bdbSetAttrReq.bdbSecondaryChannelSet               = 0x00000000; // The secondary channel set is zero for coordinators
                                                                            // so they only attempt to start a network on the
                                                                            // primary channel set
}
  else // (isRouterOrRepeaterMode)
  {
    zstack_bdbSetAttrReq.has_bdbSecondaryChannelSet           = TRUE;
    zstack_bdbSetAttrReq.bdbSecondaryChannelSet               = BDB_DEFAULT_SECONDARY_CHANNEL_SET;  // routers are allowed to use the secondary channel
                                                                                                    // set when searching for a network to join
  }

  Zstackapi_bdbSetAttributesReq( MyApp_ZstackId, &zstack_bdbSetAttrReq );

  // Start bdb in idle mode to and see if its restoring from NV
  zstack_bdbStartCommissioningReq_t zstack_bdbStartCommissioningReq;
  zstack_bdbStartCommissioningReq.commissioning_mode = BDB_COMMISSIONING_MODE_IDDLE;
  Zstackapi_bdbStartCommissioningReq( MyApp_ZstackId, &zstack_bdbStartCommissioningReq );
}


static void MyApp_SetPanId( uint16 requestedPanID )
{
  NVINTF_itemID_t nvId;

  // If joining a new pan,
  // set the global panid before starting the network
  if ( ( MyApp_nvPanID != 0xFFFF ) && ( MyApp_nvPanID != requestedPanID ) )
  {
    // Save the new panID
    nvId.systemID = NVINTF_SYSID_ZSTACK;
    nvId.subID = ZCD_NV_PANID;
    nvId.itemID = ZCD_NV_EX_LEGACY;
    MyApp_nvPanID = requestedPanID;
    zstack_user0Cfg.nvFps.writeItem( nvId, sizeof( uint16 ), &requestedPanID );

    // To force a "new" join, ForceRadioRestart
    ForceRadioRestart();
  }

  else
  {
    // Only start the network if not already done and valid PAN ID,
    if ( requestedPanID <= MAX_PAN_ID && RadioHasJoined() == FALSE )
    {
      zstack_bdbStartCommissioningReq_t zstack_bdbStartCommissioningReq;

      // Update the stack's Pan ID
      if ( MyApp_nvPanID == 0xFFFF )
      {
        nvId.systemID = NVINTF_SYSID_ZSTACK;
        nvId.subID = ZCD_NV_PANID;
        nvId.itemID = ZCD_NV_EX_LEGACY;
        MyApp_nvPanID = requestedPanID;
        zstack_user0Cfg.nvFps.writeItem( nvId, sizeof( uint16 ), &requestedPanID );
      }

      // Update the stack's device logical type NV
      if ( zgDeviceLogicalType != MyApp_DeviceLogicalType )
      {
        nvId.systemID = NVINTF_SYSID_ZSTACK;
        nvId.subID = ZCD_NV_LOGICAL_TYPE;
        nvId.itemID = ZCD_NV_EX_LEGACY;
        zgDeviceLogicalType = MyApp_DeviceLogicalType;
        zstack_user0Cfg.nvFps.writeItem( nvId, sizeof( zgDeviceLogicalType ), &zgDeviceLogicalType );
      }

      // Start or Join the PAN
      if (!bdb_isDeviceNonFactoryNew())
      {
        if ( MyApp_DeviceLogicalType == ZG_DEVICETYPE_COORDINATOR )
        {
          zstack_bdbStartCommissioningReq.commissioning_mode = BDB_COMMISSIONING_MODE_NWK_FORMATION;
          Zstackapi_bdbStartCommissioningReq( MyApp_ZstackId, &zstack_bdbStartCommissioningReq );
        }
        else
        {
          zstack_bdbStartCommissioningReq.commissioning_mode = BDB_COMMISSIONING_MODE_NWK_STEERING;
          Zstackapi_bdbStartCommissioningReq( MyApp_ZstackId, &zstack_bdbStartCommissioningReq );
        }
      }
    }
  }
}

SDK3.30 RFD Assoc Req.pcapng.zip

  • I see you use the following code to set Device Logical Type and I would suggest you to check if there is something wrong when calling those codes.

            nvId.systemID = NVINTF_SYSID_ZSTACK;
            nvId.subID = ZCD_NV_LOGICAL_TYPE;
            nvId.itemID = ZCD_NV_EX_LEGACY;
            zgDeviceLogicalType = MyApp_DeviceLogicalType;
            zstack_user0Cfg.nvFps.writeItem( nvId, sizeof( zgDeviceLogicalType ), &zgDeviceLogicalType );
    

  • I am not getting an error when calling the read or write on the ZCD_NV_LOGICAL_TYPE.

    The zgDeviceLogicalType is set to ZG_DEVICETYPE_ROUTER.

    ZDO_Config_Node_Descriptor.LogicalType is also == ZG_DEVICETYPE_ROUTER.

    The device will attempt to associate as an RFD and then spontaneously try FFD which succeeds. 

    Where can I set a breakpoint where the Association Request is being built/sent?

  • You can try to set a breakpoint in "ZMacAssociateReq" to trace and debug it.

  • OK.  I've seemed to trace it down to this...

    • The Router sends out Beacon Req and hears a bunch of different Beacons.  Some from our old ZigBee HA, some from our 'non-secure' Zigbee Pro and some from this new ZigBee 3.0 networks.  All on different PANs and sometimes different channels.
    • For some reason it chooses a ZigBee HA network (even though its not the right PAN) and sends an Association Request as a RFD because the stack profiles do not match. 
    • The router gets the association resp (zstackmsg_CmdIDs_DEV_STATE_CHANGE_IND), but see's that its not an FFD ( _NIB.CapabilityFlags & CAPINFO_DEVICETYPE_FFD == 0) and resets to try again.
    • The next time it sends out beacon requests, and chooses the correct network/PAN, but again sends an Association Request as a RFD, and again rejecting that and tries again.
    • It again tries, picks a wrong PAN, but this time one that matches the stackProfile.  This time it sends an Association Request as a FFD, but again fails as its not the right PAN.
    • Finally it tries again, pick the right PAN, sends the Association Request as a FFD and succeeds (sometimes).

    Yes, this is very hosed up.  The problem seems to stem from the router trying to associate to a device on the wrong PAN.  We have not changed our code since porting to the 3.30 SDK, so something seems to have changed in the stack.  But since this is very random and dependent on what other networks it can hear, it may have been broke all along.

    Maybe the problem is in the way we try to force the router to use a specific PAN.  We do not pre-define ZDAPP_CONFIG_PAN_ID because we don't want to hard-code the PAN.

    What we do is read some dip switches (requestedPanID) and write to ZCD_NV_PANID before we call Zstackapi_bdbStartCommissioningReq().

    // Only start the network if not already done and valid PAN ID,
    if ( requestedPanID <= MAX_PAN_ID && RadioHasJoined() == FALSE )
    {
      zstack_bdbStartCommissioningReq_t zstack_bdbStartCommissioningReq;
    
      nvId.systemID = NVINTF_SYSID_ZSTACK;
      nvId.subID = ZCD_NV_PANID;
      nvId.itemID = ZCD_NV_EX_LEGACY;
      zstack_user0Cfg.nvFps.writeItem( nvId, sizeof( uint16 ), &requestedPanID );
    
      // Start or Join the PAN only if it did not do a an NV_RESTORE
      if ( !bdb_isDeviceNonFactoryNew() )
      {
        zstack_bdbStartCommissioningReq.commissioning_mode = BDB_COMMISSIONING_MODE_NWK_STEERING;
        Zstackapi_bdbStartCommissioningReq( H8Interface_ZstackId, &zstack_bdbStartCommissioningReq );
      }
    }
    

    Note: On the very first power-up or if the pan dipswitches change we call Zstackapi_bdbResetLocalActionReq() to go to the Factory New state.

    Again, this was all working fairly reliably with the 3.20 SDK.   

    The majority of changes in moving from 3.20 to 3.30 was in using the .syscfg to define the hardware and stack.  So I'm also attaching my .syscfg to see if you think something is mis-configured that could be causing this behavior.

    Please let me know if you see anything awry here.  We've been going at this for almost a year and this is the second major change that was made to the stack/tool chain.  We're running out of time (and confidence) in getting this all to work.

    Thanks,

    - Bill

    2845.ZFR183x_PWB.zip

  • Hi,

    When you used the 3.20 SDK, did you also run the devices near your other networks?

    The BDB function bdb_filterNwkDisc should, among other criteria, filter out Beacons which do not match the PANID specified by zgConfigPANID.
    Can you see if the un-targetted beacons are filtered out by the end of the function?

    Although zgConfigPANID is initialized with ZDAPP_CONFIG_PANID, it would be overwritten by NV item ZCD_NV_PANID if the startup option (zgReadStartupOptions()) does not indicate ZCD_STARTOPT_DEFAULT_CONFIG_STATE (see beginning of zgInit).
    Is your function ForceRadioRestart writing to the startup options? If yes, what value are you writing in it?

    Regards,
    Toby

     

     

  • Hi Bill,

    Are you able to provide an update based on Toby's feedback and your recent investigations?  This issue does not appear to be related to the SysConfig file, however a new feature of Z-Stack 3.5.0 integrates the multipage NV driver: http://dev.ti.com/tirex/content/simplelink_cc13x2_26x2_sdk_3_30_00_03/docs/zigbee/release_notes_zigbee_3_5_0.html 

    When you port your application do you add your files to an imported default v3.30 example?  I do not recommend that you modify zstack_user0Cfg outside of the main file, instead you could use osal_nv_write for ZCD_NV_PANID and Zstackapi_sysConfigWriteReq for writeReq.panID.  There are examples available in bdb.c and zcl_sampleapps_ui.c.  Please let us know of any progress that is made.

    Regards,
    Ryan

  • Hey Toby/Ryan,

    I'm actually out of the office until the end of the year, so I'm not able to run any tests.

    When I did the port, I started with zr_generic app, rearranged things and added our files.  

    We noticed that the NV system changed.  One of our other engineers is seeing an exception with it running our of NV space. Just got this update this morning...

    My VMA ZFR radio was not joining the zigbee network this morning. Connecting up the debugger to the radio I’m seeing function NVOCMP_newItem fail at “Out of NV.”. 

    ...but we have been using zstack_user0Cfg exclusively in our code.  Could all be related.  Do we just replace these with osal_nv_init/read/write? Even for our proprietary NVs?

    - Bill

  • You can also reference the doorlock/doorlockcontroller projects for examples on how application NV memory is modified.  I also recommend the Non-Volatile Memory Items section of the User's Guide: http://dev.ti.com/tirex/content/simplelink_cc13x2_26x2_sdk_3_30_00_03/docs/zigbee/html/zigbee/z-stack-overview.html#non-volatile-memory-items

    Here is the latest Migration Guide: http://dev.ti.com/tirex/content/simplelink_cc13x2_26x2_sdk_3_30_00_03/docs/zigbee/html/zigbee-guide/zstack3.4.0-to-zstack3.5.0.html 

    Regards,
    Ryan

  • Hi Bill,

    Following up on this post for clarification: osal_nv_write hard-codes the system id to be the stack so it is not to be used for application NV items (zclport_writeNV would be used in this case).  The function pointers can work for either situation since the system ID can be selected.  I have confirmed with the Software Development Team that you should be able to use nvFps.writeItem in this context, my previous suggestion was because I had not before seen zstack_user0Cfg used outside of the main file.

    If a device is attempting to associate as a RFD then it is believed to be a ZED.  That is why I am assuming the corruption of NV items ZCD_NV_LOGICAL_TYPE, ZCD_NV_PANID, and ZCD_NV_NIB in particular.  You may be able to test this by removing the NV run-time commands, this would also verify that the SysConfig and CUI settings are not a factor.  Does Zstackapi_sysNwkInfoReadReq() return the correct device type?  Is there any way that this issue could be easily replicated using LaunchPads and minor modifications to the v3.30 out-of-box genericapp examples?  I'm also curious whether you could use zstackmsg_CmdIDs_BDB_FILTER_NWK_DESCRIPTOR_IND to filter available networks, please refer to the Zigbee Security SLA for further details: http://dev.ti.com/tirex/content/simplelink_academy_cc13x2_26x2sdk_3_30_01_00/modules/zigbee/zigbee_04_security/zigbee_04_security.html

    Regards,
    Ryan

  • Ryan,

    As I mentioned above, the Router is trying to associate as a RFD because the stack profile of the network that it is choosing does not match.  I've hit a breakpoint here.

    void ZDApp_NodeProfileSync( uint8_t stackProfile )
    {
      if ( ZDO_Config_Node_Descriptor.CapabilityFlags & CAPINFO_DEVICETYPE_FFD  )
      {
        if ( stackProfile != zgStackProfile )
        {
          ZDO_Config_Node_Descriptor.LogicalType = NODETYPE_DEVICE;
          ZDO_Config_Node_Descriptor.CapabilityFlags = CAPINFO_DEVICETYPE_RFD | CAPINFO_POWER_AC | CAPINFO_RCVR_ON_IDLE;
          NLME_SetBroadcastFilter( ZDO_Config_Node_Descriptor.CapabilityFlags );
        }
      }
    }
    

    The question is why is the device choosing to associate to this HA network in the first place?  We set the PAN ID using dip switches.  It may be the way that we are using these dip switches to set  zgApsUseExtendedPANID and zgConfigPANID (and their associated NVs)?  We've been doing it basically the same way since the CC2430 days.  Its been working fine until this latest port to the 3.30 SDK.  

    Do you have an example program where the user can specify the PAN ID of the coordinator and the router at run time (like through the CUI?)?    

  • Yes, this is a feature of the CUI: http://dev.ti.com/tirex/content/simplelink_cc13x2_26x2_sdk_3_30_00_03/docs/zigbee/html/zigbee/application_overview.html#pan-id-screen 

    I highly recommend reviewing uiActionProcessConfigurePanId of zcl_sampleapps_ui.c, I'm still noticing that none of the attached code uses Zstackapi_sysConfigWriteReq for writeReq.[has_panID/panID]

    Regards,
    Ryan

  • I'll take a look that uiActionProcessConfigurePanId .   I'll also try using Zstackapi_sysConfigWriteReq rather than explicitly writing the NVs.  In the end I don't see any difference, but it's worth a try.

    One thing I did notice is that the sample programs don't set/use zgApsUseExtendedPANID.  We've been setting this to the MFR_ID+PANID on the coordinator, but leave it at the default for the routers.  (eg for PANID=33 the Extended PANID is set to 00:12:4b:01:00:00:00:21) 

    I recall this was necessary way back on our old HA system.  Not sure why, but we've continued to do this without issue through several generations of 2430, 2530 and now 1352s.

    Could this be messing things up?  .

  • Please keep in mind that NV memory is used for restarts, not necessarily actions taken during the current run-time.  I don't imagine that setting the zgApsUseExtendedPANID on the ZC is causing this particular issue but I have not tested or evaluated it.

    Regards,
    Ryan

  • From what I can see, I don't think setting the Ext Pan ID should cause problems either.

    I'm attaching some screen captures from a debug session I had as well as a wireshark capture that shows the behavior. These weren't being taken at the same time because of all the breakpoints, but I think it clearly shows that something is going wrong.  The zgConfigPANID == 33 throughout the session, but the router attempts to join different networks as a RFD and then FFD.

    Again, I won't be in the office until 1/3 to experiment with anything.  But if you have any suggestions I'll give it a go when I get back. 

    One thing I'll try is to get a Launchpad zr_doorlock app running and configure its pan to join our network and see how it behaves in our mixed network environment.

    - Bill

    /cfs-file/__key/communityserver-discussions-components-files/158/SDK3.30-Join-Issues.docx

    /cfs-file/__key/communityserver-discussions-components-files/158/2548.SDK3.30-RFD-Assoc-Req.pcapng.zip

  • Ryan,

    I've been able to recreate this scenario using an out-of-the-box zr_doorlock application.  The zr_doorlock has been configured as shown in the attached word file and referenced wireshark captures.

    /cfs-file/__key/communityserver-discussions-components-files/158/SDK3.30-Join-Issues-12_2D00_27_2D00_19.docx

     /cfs-file/__key/communityserver-discussions-components-files/158/WireSharkScans.zip 

    I'm going to try filtering out the undesired networks in zstackmsg_CmdIDs_BDB_FILTER_NWK_DESCRIPTOR_IND.

  • Bill,

    Thank you for taking these steps, I have also been able to observe a ZR joining the wrong PAN ID network.  This happens with both the SIMPLELINK-CC13X2-26X2-SDK v3.30 & v3.40 projects.  It seems to occur when two or more Zigbee networks are present on the same channel.  I was also able to see the ZR join a Z-Stack HA 1.2.2a network, although it did not associate as a RFD.  I will work with the SW Development Team to discover the root cause and any feasible workarounds.  So far I've discovered that bdb_filterNwkDisc improperly increments i while decrementing ResultCount which causes a faulty number of acceptable networks to be returned.  I've had initial success making the following changes inside of bdb.c

    void bdb_filterNwkDisc(void)
    {
      networkDesc_t* pNwkDesc;
      uint8_t i = 0;
      uint8_t ResultCount = 0, ResultTotal = 0;         //CHANGE THIS LINE
    
      pBDBListNwk  = nwk_getNwkDescList();
      nwk_desc_list_release();
    
      pNwkDesc = pBDBListNwk;
      while (pNwkDesc)
      {
        ResultCount++;
        pNwkDesc = pNwkDesc->nextDesc;
      }
      ResultTotal = ResultCount;                        //ADD THIS LINE
    
      if(pBDBListNwk)
      {
        pNwkDesc = pBDBListNwk;
    
        if(pNwkDesc)
        {
          for ( i = 0; i < ResultTotal; i++, pNwkDesc = pNwkDesc->nextDesc )        //CHANGE THIS LINE
    ...

    Please share the results of your zstackmsg_CmdIDs_BDB_FILTER_NWK_DESCRIPTOR_IND investigation when possible, however I do not think that it will alleviate the problem.

    Regards,
    Ryan

  • Ryan,

    Thanks for confirming the issue.

    BUT FIRST...SDK3.40???!!! I'm still trying to get through porting to SDK3.30.

    I also see that there's a new CCS. Is it required to update to this too?

    Anyway, here's what I added to our app and it seems to be working...

        case zstackmsg_CmdIDs_BDB_FILTER_NWK_DESCRIPTOR_IND:
        {
          /*   User logic to remove networks that do not want to join
           *   Networks to be removed can be released with Zstackapi_bdbNwkDescFreeReq
           */
          // vvvvvvvvvvvvvvvvvvvv JCI Start vvvvvvvvvvvvvvvvvvvv
          networkDesc_t *pNetworkDesc;
          networkDesc_t *pNextNetworkDesc;
    
          pNetworkDesc = (networkDesc_t *)(pMsg->pReq);
          while (pNetworkDesc != NULL)
          {
            pNextNetworkDesc = pNetworkDesc->nextDesc;
            if (pNetworkDesc->panId != My_panIdSwValue ||          // toss out networks not on the right PAN
                pNetworkDesc->stackProfile != 2 ||                 // toss out non ZigbeePro networks
                pNetworkDesc->routerCapacity == FALSE )            // toss out networks with no capacity
            {
              zstack_bdbNwkDescFreeReq_t bdbNwkDescFreeReq;
              bdbNwkDescFreeReq.nodeDescToRemove = pNetworkDesc;
              Zstackapi_bdbNwkDescFreeReq(My_ZstackId, &bdbNwkDescFreeReq);
            }
            pNetworkDesc = pNextNetworkDesc;
          }
          // ^^^^^^^^^^^^^ JCI End ^^^^^^^^^^^^^^^^^^^^
    
          Zstackapi_bdbFilterNwkDescComplete( H8Interface_ZstackId );
        }
        break;
    
  • Hi Bill,

    The SIMPLELINK-CC13X2-26X2-SDK maintains quarterly updates, and v3.40 was released early due to the holiday season.  As can be seen in the Release Notes, Z-Stack 3.6.0 is maintenance only so porting should be easier than in previous SDK updates.  It has several bug fixes but does not introduce any new features: http://dev.ti.com/tirex/content/simplelink_cc13x2_26x2_sdk_3_40_00_02/docs/zigbee/release_notes_zigbee_3_6_0.html 

    The one known issue exists in both SDKs and is explained in this FAQ: https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz/f/156/t/864899 

    Since v3.30 is also production-ready then it is entirely your decision whether porting to v3.40 is necessary.  Although perhaps not vital I definitely recommend using the CCS version stated in the SDK Release Notes: http://dev.ti.com/tirex/explore/node?node=ADCz5HzpcJSUujy4TFI3Ig__pTTHBmu__LATEST 

    I'm glad to hear that your application is making progress.

    Regards,
    Ryan