• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 55 subscribers
  • Views 1018 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.

CC2538-CC2592EMK: Routers re connection issue with the coordinator

Viswajith K A
Intellectual 590 points
Part Number: CC2538-CC2592EMK


Hi,

we are working on a project with CC2538, by creating mesh network using zstack mesh v1.0.0.

In our project we are using ZNP stack for coordinator to act as a gateway, and nearly 100 routers to form a mesh network. So for a large network we have changed the values of network parameters as per the following document 

.

Initially we have tested with 50 routers and all were connected and worked without any issues. But when we disconnect all the routers and connect only one which is near to the coordinator, it could not connect to the coordinator. When we checked the packet sniffer, we have noticed that the bit value corresponding to the assoc flag is 0, in response packet for the beacon request from router.

Please find the attached sniffer log file. I have mentioned about the packets starting from 40468.

Earlier this bit was like

.

Is this related to the association table of ZC ? Is there any chance to fill this table completely, even if the routers were connected one by one to make a mesh network ? I think size of this table is related to the value of a network parameter NWK_MAX_DEVICE_LIST. Now this value is 10 in our code. I think the problem will be solved, if this parameter is changed to a large value. But still why every routers are trying to connect directly to the coordinator, even if they are placed away from it ? Please reply.

Packet_sniffer_log_10_02_17.psd

  • 0
    Expert 1620 points
    Hi Viswajith,

    In packet 13787 you can see that Coordinator device did have permit joining enabled and also Router/ED capacity as TRUE, which means that at that point coordinator still have entries to host devices in its assoc table, in the next device that did attempted to join (packet 13811) the coordinator set all its flags to FALSE (Router and ED capacity).
    After this all the nodes did join the network trough the other routers in the network become children of those existing routers, not as children of the coordinator.
    In that version of the stack, router devices does not expire from the assoc table in the coordinator, which means that the coordinator will not release those entries and will not accept more devices as it's children unless it is assoc is cleared (clear the Nv if you have it enabled or power cycle if you do not have Nv enabled).

    If the devices that you were trying to join around packet 40463 were the same that already joined the network, I suggest to enable the Nv, so those do not need to perform association again and not commissioned devices can join those routers.

    Hope this helps!
  • 0 in reply to Luis Luna
    Intellectual 590 points
    Hi,

    Thanks for the reply. Is there any chance to clear the assoc table manually through any api ? Because we can't reboot the coordinator frequently to clear the table. Also we need to enable the NV restore to retain the network.
  • 0 in reply to Viswajith K A
    Guru 735695 points
    You can try to use API AssocRemove in AssocList.h.
  • 0 in reply to Viswajith K A
    Expert 1620 points
    You could read/write the assoc table Nv entries through the serial interface using the MT API, but I think that you need to reboot the coordinator in order to update all the tables accordingly. This method also requires that the ZC have Nv enabled, because from this you are reading/writing the entries.