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.
CC2530: Assoc. not reported + Gateway/ZNP gets non responsive - ZIGBEE-LINUX-SENSOR-TO-CLOUD_1.0.1
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.
--Electronics & Software Engineer in France
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:
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?
To better aid the community, please click on the "This Resolved my issue" button whenever a post answers your question!
We are glad that we were able to resolve this issue, and will now proceed to close this thread.
If you have further questions related to this thread, you may click "Ask a related question" below. The newly created question will be automatically linked to this 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.
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.
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
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.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.