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.

SIMPLELINK-CC13X2-26X2-SDK: ZNwkTableFull

Part Number: SIMPLELINK-CC13X2-26X2-SDK
Other Parts Discussed in Thread: SYSCONFIG, CC2652R, Z-STACK

A Zigbee2MQTT user with 138 devices on the network is getting NwkTableFull errors (https://github.com/Koenkk/zigbee2mqtt/issues/13180). What table should be increased to prevent this? The firmware is compiled with the following options:

#define MT_SYS_KEY_MANAGEMENT 1
#define FEATURE_NVEXID 1

// Increase frame retries
#define ZMAC_MAX_FRAME_RETRIES 7
#define NWK_MAX_DATA_RETRIES 4

// Increase MAC buffers
#undef MAC_CFG_TX_DATA_MAX
#define MAC_CFG_TX_DATA_MAX 20
#undef MAC_CFG_TX_MAX
#define MAC_CFG_TX_MAX 32
#undef MAC_CFG_RX_MAX
#define MAC_CFG_RX_MAX 20

// Save memory
#undef NWK_MAX_BINDING_ENTRIES
#define NWK_MAX_BINDING_ENTRIES 1
#undef APS_MAX_GROUPS
#define APS_MAX_GROUPS 1

// Increase NV pages to 3 to allow for bigger device tables
#undef NVOCMP_NVPAGES
#define NVOCMP_NVPAGES 3

// Disabling MULTICAST is required in order for proper group support.
// If MULTICAST is not disabled, the group adress is not included in the APS header
#define MULTICAST_ENABLED FALSE

// Increase the max number of boardcasts, the default broadcast delivery time is 3 seconds
// with the value below this will allow for 1 broadcast every 0.15 second
#define MAX_BCAST 30

/**
 * Enable MTO routing
 */
#define CONCENTRATOR_ENABLE TRUE
#define CONCENTRATOR_DISCOVERY_TIME 100
#define CONCENTRATOR_ROUTE_CACHE TRUE
#define MAX_RTG_SRC_ENTRIES 255
#define SRC_RTG_EXPIRY_TIME 2

/**
 * Scale other device tables appropriately
 */
#define NWK_MAX_DEVICE_LIST 50
#define ZDSECMGR_TC_DEVICE_MAX 200
#define MAX_NEIGHBOR_ENTRIES 20
#define MAX_RTG_ENTRIES 255

/**
 * Reduce the APS ack wait duration from 6000 ms to 1000 ms (value * 2 = value in ms).
 * This will make requests timeout quicker, in pratice the default timeout of 6000ms is too long.
 */
#define APSC_ACK_WAIT_DURATION_POLLED 500

// From https://www.ti.com/lit/an/swra650b/swra650b.pdf
#define LINK_DOWN_TRIGGER 12
#define NWK_ROUTE_AGE_LIMIT 5
#define DEF_NWK_RADIUS 15
#define DEFAULT_ROUTE_REQUEST_RADIUS 8
#define ZDNWKMGR_MIN_TRANSMISSIONS 0
#define ROUTE_DISCOVERY_TIME 13
#define MTO_RREQ_LIMIT_TIME 5000

  • Hey Koen,

    This may indicate that they have exceeded the maximum number of nodes that can be directly associated to the ZNP.  Although the immediate solution may be to increase the NWK_MAX_DEVICE_LIST or MAX_NEIGHBOR_ENTRIES, it would be better still to create a more robust mesh network.  Do you know what their network topology is, concerning whether they have several routers in a mesh configuration (multiple hops) or if all nodes are end devices directly connected to the ZNP?  The former is ideal so that the ZNP is not overtaxed by a significant number of directly associated devices.

    Regards,
    Ryan

  • Hey Ryan,

    We experimented with different table sizes but this didn't fix the issue. In the network some address conflicts messages are sent after the coordinator does a device announce. The device announce of the coordinator has extended address ff:ff:ff:ff:ff:ff:ff:ff while the real address is 00:12:4b:00:21:5f:fe:a6, could this cause the issue?

      

  • Hey Koen,

    This could be NV corruption.  Has the SysConfig -> NVSINTERNAL Region Size and NVOCMP_NVPAGES definition been increased to allow for more non-volatile flash memory space?.  This is all detailed in the Flash Memory section of the Z-Stack User's Guide.

    Regards,
    Ryan

  • Hi Ryan,

    I don't expect this is the issue, I've tried increasing the pages to 4 but the issue still occurs. Also tried reducing the HEAPMGR_SIZE from 0x4E20 to 0xC000 but this doesn't help either. According to my calculation 2 pages should be enough, so with 4 pages I don't expect the issue is related to this.

    Calculation:

    NWK_MAX_DEVICE_LIST = 50 * 23 bytes = 1150 bytes
    ZDSECMGR_TC_DEVICE_MAX = 200 * 27 bytes = 5400 bytes

    NWK_MAX_BINDING_ENTRIES = 1
    NWK_MAX_ADDRESSES = NWK_MAX_DEVICES + NWK_MAX_REFLECTOR_ENTRIES + NWK_MAX_SECURE_PARTNERS = (50 + 1) + 1 + (200 + 5) = 257 * 19 bytes = 4883 bytes

    TOTAL = 11433 bytes + 2.3 kb = 13733 bytes
    1 NV page = 0x2000 bytes = 8192 bytes
    REQUIRED NV PAGES = +- 1.67 NV page

  • Thank you for giving specific details.  I had forgotten to mention non-volatile-memory-low-voltage-detection in my last reply.   It could be possible that the flash memory is being corrupted while writing during low voltage or unsteady power supply situations.  They could further step through zmain_ext_addr if they are able to debug the faulty device.  The ZC would have to be factory reset to work properly again, in the future they could define NVOCMP_MIN_VDD_FLASH_MV and create a ZC node backup.

    Regards,
    Ryan

  • In my application, 2-pages of NV is not enough, My coordinate will support 200 nodes. You had better set 3 pages.

  • We found the issues related to the strange device announces; turns out the adapter was malfunctioning, after switching to another adapter (with CC2652R chip) the issue doesn't appear anymore.

    The NwkTableFull errors are still appearing though. I've increased both the NWK_MAX_DEVICE_LIST and MAX_NEIGHBOUR_ENTRIES to 100 which should be big enough. Are there any other tables which can cause the NwkTableFull errors?

  • MAX_RTG[_SRC]_ENTRIES and ZDSECMGR_TC_DEVICE_MAX are important as well, although these appear to already be accounted for.  NWK_MAX_DEVICE_LIST and MAX_NEIGHBOUR_ENTRIES should not be too large as they could cause instability on the ZNP/ZC given the excessive amount of traffic caused by directly neighboring/associated devices.  If possible, you could debug the ZNP to determine which Z-Stack function returns the error.

    Regards,
    Ryan