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.

  • Resolved

CC2530: ZNP stops working properly after ZNwkTable full - ZSTACK3.0.2

Expert 3000 points

Replies: 5

Views: 105

Part Number: CC2530

I performed a new debug session on with the ZIGBEE-LINUX-SENSOR-TO-CLOUD_1.0.1 gateway and Z-Stack 3.0.2.
I created this related question to make it easier to know which test we are talking about.


This time the associations worked, but the system became dysfunctionnal again when the NwkTableFull occurred.

By comparing this trace to the parent related (parent) question, it may also be possible to understand why association is working here and not in the parent question.

The first device probably did a rejoin because it was added without opening the network.
The second device alos initiated association without user intervention.


[2020-11-20 14:28:22.193878] [NWK_MGR/HNDL] DEBUG : - AddDevice Complete on 0xCCCCCCFFFE3A2F33
[2020-11-20 14:30:29.623221] [NWK_MGR/HNDL] DEBUG : - AddDevice Complete on 0x70B3D5B13001011E
[2020-11-20 14:30:50.081206] [NWK_MGR/HNDL] DEBUG : - AddDevice Complete on 0x00158D00047B8369
[2020-11-20 14:32:16.614576] [NWK_MGR/HNDL] DEBUG : - AddDevice Complete on 0x000D6F0012A0CCF8
[2020-11-20 14:32:31.549518] [NWK_MGR/HNDL] DEBUG : - AddDevice Complete on 0x00124B000760BB0A
[2020-11-20 14:33:56.656909] [NWK_MGR/HNDL] DEBUG : - AddDevice Complete on 0x70B3D5B13001011E

And then, from the next point onwards (ZNwkTableFull), the ZNP stops behaving properly:

[2020-11-20 14:39:42.804931] > [ZDO/SRSP] **EXT_ROUTE_DISC** ZNwkTableFull (SYS:5/TYPE:60/CMD:45) ( 6)::fe 01 65 45 c7 e6


While it is possible to increase the NwkTable sizes, an insufficient table size should not result in the ZNP breaking down.

Also, I do not understand how the NwkTable gets full in the current situation, nor do I know how to clear it.

I examined the source code and I found that the table sizes are set in constant "variables" so that they can be passed to the NLME that is delivered as a compiled library. I can not examine the NLME source code of course.

I did not see how memory is allocated for these tables, so I suppose that this is done inside the library using osal_malloc for instance.

Hopefully we (=TI & I) can fix this.


The logs are joined as usual.

AssociateOkThenNwkTableFullBreaksSystem.zip

--
Electronics & Software Engineer in France

  • Hi Mario,

    How many devices have joined the network at one point or another in total?  In regards to cleaning up table entries, you could attempt asking outdated/unwanted items to leave with ZDO_MGMT_LEAVE_REQ or use ZDO_SEC_DEVICE_REMOVE and/or ZDO_EXT_SEC_APS_REMOVE_REQ to manually remove this information locally.  Here are some relevant E2E threads:

    https://e2e.ti.com/support/wireless-connectivity/zigbee-and-thread/f/158/t/940819/
    https://e2e.ti.com/support/wireless-connectivity/zigbee-and-thread/f/158/t/892062/ 

    I can see in your sniffer log that the ZNP stops communicating at a seemingly random moment and without any recent noteworthy network action.  This raises the possibility of a memory leak.  I also notice that it is never responding to the repeating IEEE Address Request from a ZED.  Once you are able to debug the ZNP it would be good to set a breakpoint inside ZDP_IncomingData -> zdpProcessAddrReq and determine why a response is never returned.  Can you please remind me of the behavior once the ZNP is reset?

    Regards,
    Ryan

    To better aid the community, please click on the "This Resolved my issue" button whenever a post answers your question!

  • In reply to Ryan Brown1:

    This is the list of devices shown in the textual UI:

    00:12:4B:00:10:22:82:77 0000 01 COMBINED INTERFACE <0501> | F2 0061(A1E0)
    CC:CC:CC:FF:FE:3A:2F:33 69F6 01 0301(HA)<000A:0000> <000a> <0020><0201:0000><0201:0012> <0201> <0204> <0b05>                                 
    70:B3:D5:B1:30:01:01:1E 8C47 0E 0053(HA) <0b04> <0702> <0b01> <000a>                                                                        
    00:15:8D:00:04:7B:83:69 79D8 01 TEMPERATURE SENSOR <ffff> <0402><0403:B5B2><0403:02B9><0403:0000><0403:02BC> <0403> <0405>                  
    00:0D:6F:00:12:A0:CC:F8 F2AB 01 IAS ZONE<0001:B5B2><0001:02A4>, Enrolled/FIRE_SENSOR <0500>                                                 
    00:12:4B:00:07:60:BB:0A DABA 01 IAS ZONE<0000:0004><0000:0005><0000:0007>, Not enrolled/ZONE_UNALLOCATED, IDLE <0500>                       
    

    This corresponds to the total number of devices added.  One of them was "Added" twice:

    $ grep 'AddDevice Complete' AssociateOkThenNwkTableFullBreaksSystem.log
    [2020-11-20 14:28:22.193878] [NWK_MGR/HNDL] DEBUG  : - AddDevice Complete on 0xCCCCCCFFFE3A2F33
    [2020-11-20 14:30:29.623221] [NWK_MGR/HNDL] DEBUG  : - AddDevice Complete on 0x70B3D5B13001011E
    [2020-11-20 14:30:50.081206] [NWK_MGR/HNDL] DEBUG  : - AddDevice Complete on 0x00158D00047B8369
    [2020-11-20 14:32:16.614576] [NWK_MGR/HNDL] DEBUG  : - AddDevice Complete on 0x000D6F0012A0CCF8
    [2020-11-20 14:32:31.549518] [NWK_MGR/HNDL] DEBUG  : - AddDevice Complete on 0x00124B000760BB0A
    [2020-11-20 14:33:56.656909] [NWK_MGR/HNDL] DEBUG  : - AddDevice Complete on 0x70B3D5B13001011E
    

    I performed a reset on the ZNP only, it still reports "Invalid Parameter" , renews its ZNwkTableFull message, and returns some ZSuccess messages on ROUTE_DISC .

    I attache a log where this happens.

    One can see that the reset was effective:

    [2020-11-20 20:50:31.790175] > [SYS/AREQ] **RESET_IND** EXTRST(1) Protocol 2 ProductID 2 SWVer 2.7.2    (SYS:1/TYPE:40/CMD:80) ( 11)::fe 06 41 80 01 02 02 02 07 02 c1

    With regards to debugging the ZNP, I was going to set that up.

    1563.AssociateOkThenNwkTableFullBreaksSystem.zip

    --
    Electronics & Software Engineer in France

  • In reply to Mario DW:

    I succeeded to setup a debug environment, but in the "CC2531-Debug" profile and without SBL.
    Because of the SBL sector protections, I had to erase the entire memory and I could not reproduce the issue yet.
    I also added a configuration to reduce the NWK_TABLE to the original settings in this devices setup.

    Possibly "TI" should suggest to modify these values only for ROUTERS and COORDINATORS and not for END DEVICES (so there should be an appropriate #ifdef).

    Possibly, to reproduce the ZNwkTableFull related issue, the table sizes could be reduced so that the TableFull condition is triggered more easily with hopefully the undesired behavior as a result.

    For now we have to work with the existing logs only to identify this issue.

    --
    Electronics & Software Engineer in France

  • In reply to Mario DW:

    Actually there is another case like this that can be found in earlier logs privided as  AssocNonReported_ZNP_KO .

    What seems to be common in these two case is that the ZNwkTableFull is reporetd after a resett:

    This is the first ZNwkTableFull in the other log:

    [2020-11-08 17:37:38.924501] > [ZDO/SRSP] **EXT_ROUTE_DISC**    ZNwkTableFull   (SYS:5/TYPE:60/CMD:45) (  6)::fe 01 65 45 c7 e6
    

    In that case ZNwkTableFull appears right after reset and before ZInvalidParameter .

    In the case reported in this thread, ZInvalidParameter appears first and then ZNwkTableFull  .  But that is because of the order of the requests AF_DATA_REQUEST_EXT and ZDO_EXT_ROUTE_DISC .

    So somehow this happens on reset, and it "immediately" impacst AF_DATA_REQUEST_EXT and ZDO_EXT_ROUTE_DISC . .  That should reduce the number of possibilities.

    here is the link to the logs: 5047.AssocNonReported_ZNP_KO.zip) , reported here

    --
    Electronics & Software Engineer in France

  • In reply to Mario DW:

    I determined the root cause of this issue which is related to how the ZNP works and a limitation of the gateway that I'll have to improve on.

    So you do not need to investigate this anymore and you can concentrate on the other question still open.

    --
    Electronics & Software Engineer in France

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.