• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 55 subscribers
  • Views 1711 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

CC2652P: How many child devices can the coordinator allow to join the network?

Galaxy Yue
Prodigy 545 points
Part Number: CC2652P
Other Parts Discussed in Thread: Z-STACK

Hi Team,

SDK:simplelink_cc13xx_cc26xx_sdk_6_40_00_13

Project requirements meet the requirements of 200 sub-devices (no routing devices) directly connected to the coordinator.

Modify macro definition

ZDSECMGR_TC_DEVICE_MAX changed from default value 40 to 200

NWK_MAX_DEVICE_LIST changed from default value 20 to 200

The compilation did not prompt any errors. The test captured the LOG and found that when joining the network, the beacon request, association request, association response, transport key, and device announce all went smoothly. The problem was that in the subsequent TCLK update process, the sub-device sent multiple requests in succession. The key has not received a response from the coordinator. After timeout, the sub-device will automatically leave the network.

If I restore the above macro definition to default, everything goes smoothly.

Please tell me, how many sub-devices can the coordinator allow at most to join the network? Is exceeding the maximum causing the problem? Or did I modify the macro definition incompletely and miss some parameters?

join nwk log (1).zip

I have  told for 200 .

Then the customer asked:Can you give me some guidance on which macro definitions need to be modified to support 200 devices? I checked which step I made a mistake in, so I encountered the problem mentioned earlier.

200, does it refer to the mode of direct connection to the coordinator (no routing device), or is it partly connected to the coordinator and partly connected to the routing device, adding up to 200?

Best Regards,

Galaxy

  • 0
    TI__Guru**** 219057 points

    Hi Galaxy,

    The most immediate issue is that there is likely not enough NV memory to store 200 device TCLK entries by default, hence the NV initialization and subsequent TCLK entry requests fail during the TCLK update process.  You can refer to Modifying Non-Volatile Memory Allocation from the Z-Stack User's Guide for more details.  If this does not resolve the issue, then you can further debug NVOCMP_initNv and ZDSecMgrTclkReq from the ZC project code to isolate the issue.

    I would advise that SWRA650 be reviewed, although this guide is for mesh network performance.  In practice, large star networks can put too much strain on the ZC if multiple device reports and/or data requests are coming in at once, or if the ZC has to queue too many messages for sleepy ZEDs which haven't checked in recently.  TI has not performed rigorous tests for such a large star network using Z-Stack.

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    TI__Prodigy 545 points

    Hi Ryan，

    1. I have tested expanding nv memory and increasing NVOCMP_NVPAGES by 5 (currently 3), but it has no effect.

    2. Debugging ZDSecMgrTclkReq, I found that when calling APSME_SearchTCLinkKeyEntry(initExtAddr,&found, &TCLKDevEntry), the variable found feedback was false. Because the source code of this function is not open, I cannot continue the analysis here for unknown reasons.

    Best Regards,

    Galaxy

  • 0 in reply to Galaxy Yue
    TI__Guru**** 219057 points

    "Projects Properties’ Build → Arm Compiler → Predefined Symbols as well as Build → Arm Linker → Advanced Options → Command File Preprocessing...Users will also need to modify the aforementioned NVOCMP_NVPAGES=2 locations along with Region Base and Region Size settings in the project’s .syscfg file TI Drivers → NVS → Internal Flash."  Did you do this as well?  List all locations modified in detail.  Make sure to erase all device memory before reprogramming.

    Regards,
    Ryan