CC2652R: ZNP not sending incoming messages for some devices.

Hi Akhilesh,

I would like to know more about the behavior described.  Is there a large amount of network and UART activity around the time these messages are not processed?  Do the lost commands always come from the same devices or can it happen for any device on the network?  Have you been able to correctly receive similar messages before?  You can try to increase the NWK_MAX_DATABUFS_* from nwk_globals.c, the RX/TX ring buffer sizes in SysConfig's UART2 module, and the NPI_UART_BR from npi_tl_uart.h

Regards,
Ryan

Hi Ryan,

There is no activity associated with the ZNP at the point and also no UART. The network, however has a bunch of link status messages going on (LINK STATUS INTERVAL is set to 60s).

The lost commands happens on random devices on the network. Another observation is that if I power cycle the ZNP and retry, this device works fine but later the same happens to a different device. Initially we suspected this was happening to devices with low RSSI but that wasn't the case, even after moving the device closer the same issue happened.

We will try to tweak the buffers and check. This is also on an older SDK(4.40), will try with the latest one.

Thanks
Akhilesh

What changes have you made to the default ZNP so far and which SIMPLELINK-CC13XX-CC26XX-SDK are you using?  Be sure to increase the NV memory allocation and heap (it can be statically allocated in older SDKs).  When the issue occurs, is the ZNP unable to receive any messages from a particular device?  Can you replicate with a single device sending packets continuously or is a large network required?  Are you furthermore able to debug the ZNP to determine whether it receives (but never fully processes) the incoming message?

Regards,
Ryan

Hi,

SDK is 4.40. The changes are added at the end.
We have not made any changes for the heap.

When the issue occurs, is the ZNP unable to receive any messages from a particular device? 
The device only responds to requests from the ZNP, and yes none of these requests are processed. Will try to get a sniffer log for this.

Can you replicate with a single device sending packets continuously or is a large network required?
Does not replicate with sending packets continuously if it is already responding. Still unsure, but is easily reproducible in a bigger network.

Are you furthermore able to debug the ZNP to determine whether it receives (but never fully processes) the incoming message?
We will be setting this up and debugging into in sometime. Will update

Thanks
Akhilesh

P.S. Configuration settings

// 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 250
#define CONCENTRATOR_ROUTE_CACHE TRUE
#define MTO_RREQ_LIMIT_TIME 5000
#define MAX_RTG_SRC_ENTRIES 200
#define SRC_RTG_EXPIRY_TIME 0
#define ROUTE_EXPIRY_TIME 0

/**
 * Scale other device tables appropriately
 */
#define NWK_MAX_DEVICE_LIST 100
#define ZDSECMGR_TC_DEVICE_MAX 200
#define MAX_NEIGHBOR_ENTRIES 100
#define MAX_RTG_ENTRIES 100

// nwk link status repeat interval
#define NWK_LINK_STATUS_PERIOD 60

// number of failed messages before it marks the neighbor as inactive
#define LINK_DOWN_TRIGGER 12

// neighbor table marking neighbors are unstable very fast
#define NWK_ROUTE_AGE_LIMIT 15

// route request radius needs to be adjusted to limit the discovery storm in worst case scenario
#define DEFAULT_ROUTE_REQUEST_RADIUS 15

// disable frequency agility
#define ZDNWKMGR_MIN_TRANSMISSIONS 0

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

// From www.ti.com/.../swra650b.pdf
#define DEF_NWK_RADIUS 15
#define ROUTE_DISCOVERY_TIME 13

I would suggest making more heap space if it is statically assigned.  A sniffer log will help further understand if there is an issue with the frame counter or network security.  If you are increasing NVOCMP_NVPAGES then make sure to alter the Region Base and Size in SysConfig -> NVS -> NVSINTERNAL as well, along with the command linker file (depending on the SDK version used, the allocations may not be automatically changed).  You might try to increase to four total NV flash memory pages if possible.  I also recommend evaluating the latest SDK to determine whether there are any noticeable improvements.  TI's R&D Team evaluates a large network setup of ~100 nodes quarterly to confirm a reliable and robust solution.

Regards,
Ryan