• State TI Thinks Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 56 subscribers
  • Views 126 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

CC2530: ZStack 2.51 a version network key issue

Cherry Zhou
Mastermind 22235 points
Part Number: CC2530
Other Parts Discussed in Thread: Z-STACK

Issue:

The customer distinguishes different domains by modifying the parameters of DEFAULT_TC_LINK_KEY, and the nodes are modified. However, the actual operation of two domain networks is still free to group, and it is not possible to separate the two networks.

The customer would like to know  is there any other way to achieve it.

The original contents of the nwk_globals.h file are as follows:

// ZigBee Alliance Pre-configured TC Link Key - 'ZigBeeAlliance09'
#define DEFAULT_TC_LINK_KEY { 0x5a, 0x69, 0x67, 0x42, 0x65, 0x65, 0x41, 0x6c,\
0x6c, 0x69, 0x61, 0x6e, 0x63, 0x65, 0x30, 0x39 }

The modified contents of the nwk_globals.h file are as follows:

// ZigBee Alliance Pre-configured TC Link Key - 'ZigBeeAlliance09'
#define DEFAULT_TC_LINK_KEY { 0x20, 0x69, 0x67, 0x42, 0x65, 0x65, 0x41, 0x6c,\
0x6c, 0x69, 0x61, 0x6e, 0x63, 0x65, 0x30, 0x20 }

Thanks!

Best Regards,

Cherry Zhou

  • 0
    Guru 735455 points

    Z-Stack 2.5.1a is obsolete. It’s recommended to use latest Z-Stack 3.0.2

  • 0
    TI__Guru**** 202276 points

    Hi Cherry,

    Please note that if the same DEFAULT_KEY is used then devices will be able to communicate freely even without the correct TC Link Key under this deprecated Zigbee Specification.  You could further separate the networks through DEFAULT_CHANLIST and ZDAPP_CONFIG_PAN_ID.  If these suggestions are not acceptable then please have the customer provide a sniffer log to further demonstrate the issue they are experiencing.

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    TI__Mastermind 22235 points

    Hi Ryan,

    Thanks for your reply!

    The latest update is as follows:

    In the following labs, the code-group network flow is as follows:

    Node Group Network Initiate Request First Step

    ZgWriteStartupOptions(ZG_STARTUP_SET, ZCD_STARTOPT_DEFAULT_NETWORK_STATE); // Delete the current network information

    Resetflag[0] = 1 ; // Terminal reset flag set 1

    Osal_nv_write(0x0402, 0, 12, resetflag);// pattern write to flash

    SystemReset(); // Restart the MCU

    The second step node, ZDOInitDevice(0); is executed based on the flag bit after the device reset Before reset, the coordinator opens the entry window for 60 seconds and the device completes the network entry.

    Issue: The program that the customer burned to both coordinators is the same version, except that the key in the nwk_globals.h file is different. A coordinator is 0x20...0x20, B coordinator is 0x10...0x10; The keyf of the C routing node is divided into two burn labs, the key of the A coordinator and the key of the B coordinator.

    Result: The C-routing node can only be added to the A coordinator regardless of the key change since it has been added to the A-coordinator before.

    The customer would like to know what's the possible reason for that.

    Thanks again!

    Best Regards,

    Cherry

  • 0 in reply to Cherry Zhou
    TI__Guru**** 202276 points

    The node should never be capable of joining the ZC's network if it has a different TC Link Key and they do not share a pre-distributed NWK key.  Both ZCD_STARTOPT_DEFAULT_NETWORK_STATE and ZCD_STARTOPT_DEFAULT_CONFIG_STATE should be set for a completely factory new configuration, otherwise does the customer know if the device is rejoining its previous network or re-attempts a fresh join including network discovery?

    Regards,
    Ryan