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.

CC2652P7: CC2652P7: Application-layer delayed-start issue caused by modifying Maximum Unique TC Link Keys in Z-Stack.

Part Number: CC2652P7

image.png

Hello,

Regarding the CC2652P7 and the Zigbee zc_light project under  simplelink_cc13xx_cc26xx_sdk_8_31_01_11, my main questions are:

1. I need to build a Zigbee network with hundreds of nodes. During development, I noticed that the parameter “Maximum Unique TC Link Keys” affects the network size. When I increased this value to 200, there was an 8-second delay in the application-layer task startup. It seems that NV initialization iterates through every entry, and I don't understand why this causes such a long delay.

2. From my understanding, I am using only one fixed default TC Link Key in my network. Why is the “Maximum Unique TC Link Keys” parameter still needed to limit the number of joining nodes? In a centralized network, is this parameter mandatory?

  • Hello,

    1. I can confirm the behavior you are describing, and from what I recall the NLME_InitNV->AddrMgrInitNV usage from the ZDApp_RestoreNetworkState or ZDOInitDeviceEx functions can take an extended amount of time to initialize NV item entries item-by-item for an extended address list.  I had provided a custom solution for a customer years ago, and the resultant ZDApp.c file thus greatly outdated, but Custom_AddrMgr_InitNV from the attached file may be able to assist you:

    3323.ZDApp.c

    2. In the TCLK update process from Zigbee 3.0 each joining device requests and is delivered a unique TCLK.

    If you don't want TCLK updates then you set BDB_DEFAULT_TC_REQUIRE_KEY_EXCHANGE to FALSE (default) in bdb_interface.h for the ZC node and requestNewTrustCenterLinkKey to FALSE (non-default) in zd_sec_mgr.c for ZR/ZED nodes.

    Regards,
    Ryan