• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 55 subscribers
  • Views 1128 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.

LAUNCHXL-CC1352P: configuration of Install code on ZIGBEE 3 deveices using ZNP

mohammad rasekh60
Prodigy 200 points
Part Number: LAUNCHXL-CC1352P
Other Parts Discussed in Thread: CC1352R, Z-STACK

Hello

Im Rohan Rasekh

Currently im using 4 CC1352R boad to build a ZIGBEE3 mesh. i have followed instruction here to establish zigbee coordinator and router and end device in a simple mesh network. now i want to do the following

1. use INSTALL CODE for the mesh. im doing the following but its not working, if im missing something please inform me

  1.  on COORDINATOR
    1.  doing primary steps of reset, logical_type setting
    2. seting PAN ID using SYS_OSAL_NV_WRITE ,ID:83 value: 0xF0C0
    3. setting channels primary and secondary
    4. adding install code using APP_CNF_BDB_ADD_INSTALLCODE, im adding IEEE addresses of other boards and the installation code(0x1111111111111111F9FC) for them
    5. APP_REGESTER
    6. APP_CNF_BDB_START_COMMISSIONING : network formation
    7. APP_CNF_BDB_START_COMMISSIONING : network steering
  2. on ROUTER
    1. doing primary steps of reset, logical_type setting
    2. seting PAN ID using SYS_OSAL_NV_WRITE ,ID:83 value: 0xF0C
    3. setting channels primary and secondary
    4. adding install code using APP_CNF_BDB_SET_ACTIVE_DEFAULT_CENTRALIZED_KEY  ,installation code(0x1111111111111111F9FC)  USE GLOBAL: FALSE
    5. APP_REGESTER
  3. APP_CNF_BDB_START_COMMISSIONING : network steering

    on coordinator all is successful but router can not find the coordinator

    Write ZCD_NV_ZDO_DIRECT_CB to 1 to receive ZDO related messag is also enabled for both

    im using Z-tools 2 and Zstack3

    other matter is can i save network config ,so after power reset , they now their config?

    regards

    RASEKH

     

  • 0
    TI__Intellectual 2780 points

    Rohan,

    Install codes are supposed to be a 16-byte sequence followed by the proper 2-byte CRC, it looks like you're only using an 8-byte sequence?

    Can you also post a sniffer log of the devices attempting to associate, etc.?

    EDIT: To answer your question regarding saving network configurations even after a power reset, you are able to by making sure that NV_RESTORE is enabled.

  • 0 in reply to Sean M
    Prodigy 200 points

    hello

    thanks for your fast reply
    I'm using 16-byte sequence followed by 2byte CRC, install code is 0x01010101010101010101010101010101F9FC , and im receiving SUCCESS for it.
    for sniffer log,Ican i use SAVE option on Z tools, and post it here?

    and where can I find these attributes IDs for SYS_OSAL_NV_WRITE(like 0x0087 wich define device role)

    regards

  • 0 in reply to mohammad rasekh60
    TI__Intellectual 2780 points

    Sure that can be good. It would also be great if you could attach a sniffer log such as from Ubiqua.

    You can find the list of NV item IDs located at: c:\ti\simplelink_cc26x2_sdk_<version>\source\ti\zstack\osal\src\inc\zcomdef.h


    Best,
    Sean

  • 0 in reply to Sean M
    Prodigy 200 points

    Hello

    here are the log files from Z-tools2 for coordinator and END device

    I have added two end device IEEE addresses with Install Code for them on Coordinator but they are unable to find the network.

    one more question is , every time i want to add a new device to my mesh i should do NETWORK STREEING on Coordinator , is there anyway around it? i mean is there a way to introduce all the end devices to Coordinator(with there IEEE addresses)  and they be able to join the network when ever they become available without any NETWORK STREEING on COORDINATOR side?

    COM14(coordinator).rtf

    COM17(end device).rtf

    Regards

    Rasekh

  • 0 in reply to mohammad rasekh60
    TI__Intellectual 2780 points

    Rasekh,

    When you're adding the install code to your ZC, you need to have the IEEE address set in little endian format (least significant byte first). So it'd be {0x07, 0xD4, 0x9B, 0x18, 0x00, 0x4B, 0x12, 0x00} (The actual address will ofcourse vary if you use a different device with a different IEEE address than the one in your log you had posted.

    EDIT: As far as your network steering goes, having Network Steering enabled for a ZED to join a Zigbee network is required, plain and simple. If you're wanting to get around this in a very hacky manner, you'd have to set all of the network configuration settings into the NV, which is still a much bigger pain than turning on network steering.


    Best,
    Sean

  • 0 in reply to Sean M
    Prodigy 200 points
    thanks , it works now, by the way i have another question, when an END DEVICE or ROUTER lose its parents ,there will be an announcement on the router or end devices, but nothing on Coordinator. is there anyway to get some notification about lost child on coordinator?
  • 0 in reply to mohammad rasekh60
    TI__Intellectual 2780 points
    Rasekh,

    Glad you got it working now.

    To answer your second question:

    So ZR's do not have parents nor have a concept of a parent. They have neighbors and routing tables. Say if the next hop to destination address is broken, then an AODV route request is initiated (This is explained more in detail in the Z-Stack Overview section in the Z-Stack user's guide.

    When a ZED loses its parent, the device goes into a BDB_PARENT_LOST state, where you will get the application callback to do whatever you would like to do, such as attempt secure rejoin every N seconds. A MAC orphan notification is sent out too when the parent is lost, but not a coordinator realignment.

    So knowing these details, you can also refer to the SWRA615 (www.ti.com/.../swra615.pdf) and specifically see the Child Management section for more information about child aging, as well as the parent announce command.

    When a ZED goes into this BDB_PARENT_LOST state, it means that its outside of range for any suitable parent, so there's no way for it to communicate it lost its parent to the network. If the ZED loses the parent and another rejoins another parent, then when the old parent turns back on, it will then send out a 'parent announce' packet to resolve the parent conflicts.

    So concluding this, this new Zigbee 3.0 feature of child aging implies there is really no way for you the know if you lost your children otherwise.

    Hopefully this information helps you.

    Best,
    Sean