• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 55 subscribers
  • Views 944 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.

First byte of incoming ZCL Read Attribute frame sometimes changes to 0x05

Ville Paukkonen
Other Parts Discussed in Thread: CC2530, Z-STACK

Hi,

I am working on an implementation of a ZigBee Smart Energy compliant in-home display which uses CC2530 and ZStack 2.5.1a in order to act in a ZigBee network as an end device. The implementation is almost finished and we are preparing the device for official ZigBee conformance testing, but there is one weird issue that currently prevents many of the tests from passing reliably.

In several test cases, the test harness acting as a Trust Center sends a ZCL Read Attribute command frame in order to verify that our device sends a correct reply. However, these tests occasionally fail (about 20% of the time) because our device randomly replies with the wrong attribute. Each time this happens, the attribute ID contained in the reply has its less significant byte changed to 0x05. So if the Trust Center requests attribute 0x0000, our device sometimes replies by sending attribute 0x0005 instead, etc.

Looking at the packet traffic with a third party sniffer didn't reveal anything particularly interesting: TC sends a ZCL Read Attribute packet, its payload contains one attribute ID and it is 0x0000. Then our device sends a ZCL Read Attribute response and its payload contains attribute ID 0x0005 and its current value (or an unsupported attribute error, if the attribute ID has transformed into something unsupported).

To debug the issue further, I then modified the zstack by adding zclSendMsg(pInMsg) to zclProcessInReadCmd() in both ZNP and ZAP level code. This way, all received ZCL Read Attribute packets got relayed to application level event loop, and I was able to verify that by the time the incoming command frame got processed by ZNP in zclProcessInReadCmd(), the attribute ID had already mysteriously changed to 0x0005.

This behaviour is really baffling, since these frames are encrypted and therefore the possibility of packets getting corrupted during transmission is basically out of the question. Most of the ZCL Read Attribute packets are received correctly, but the problem still occurs often enough to prevent compliance tests from passing at the moment. It is also quite possible that similar corruption occurs with other types of command frames as well, they just haven't been tested as extensively. I have noticed that Certificate-Based Key Establishment occasionally fails for no obvious reason, and succeeds on retry, so that could be related too.

Any ideas what to do about this?

  • 0
    TI__Genius 9325 points

    Hi Ville,

    Can you check if the same problem happens with the SampleApp IPD included in the original Z-Stack 2.5.1a installation?

    I have done that test with the IPD SampleApp as is and the ESI SampleApp modified to send READ ATTRIBUTES command to the IPD and haven't seen the problem you described.

    Can you please check if there is any possibility that some part of the memory gets corrupted by your application code? For example, every memory allocation operation should be checked with its return value.

    - Cetri

  • 0 in reply to Cetri

    Hi Cetri,

    I neglected to mention that our device architecture uses CC2530 as the ZigBee Network Processor, an ARM7 as the ZigBee Application Processor, and these two are communicating over UART. So running the sample applications on our device is not trivial and requires some extra porting work.

    Anyway, the application code is not run on CC2530 so it cannot cause any memory corruption that would be related to this issue, as the ZCL Read Attribute commands are fully handled by ZNP.

    My first suspicion was that this issue could be caused by the patches we have made for the ZNP code, but the problem persisted even after I stripped almost all of the patches, leaving only the following ones:
    * value of zgPreConfigKeys in ZGlobals.c changed to TRUE
    * value of KEY_ESTABLISHMENT_REC_AGING_INTERVAL in zcl_key_establish.h increased from 1000 ms to 10000 ms
    * value of SECURE in f8wConfig.cfg changed from 0 to 1
    * TC_LINKKEY_JOIN defined in znp.cfg
    * zclGeneral_ProcessInCmd_ConfirmKeyRsp() modified slightly according to http://e2e.ti.com/support/low_power_rf/f/158/t/256374.aspx so that ZNP correctly sends the default response for Confirm Key Response Messages (otherwise the test harness we are using refuses to complete CBKE)

    I'll include the full patch file here in case you want to take a look at it. 

    Fullscreen 7065.zstack.diff Download 
    diff -urN ZStack-CC2530-2.5.1a.original/Components/stack/sys/ZGlobals.c ZStack-CC2530-2.5.1a/Components/stack/sys/ZGlobals.c
--- ZStack-CC2530-2.5.1a.original/Components/stack/sys/ZGlobals.c	2012-04-02 17:02:18.000000000 +0300
+++ ZStack-CC2530-2.5.1a/Components/stack/sys/ZGlobals.c	2013-04-15 13:30:12.889866118 +0300
@@ -168,7 +168,7 @@
 // If true, preConfigKey should be configured on all devices on the network
 // If false, it is configured only on the coordinator and sent to other
 // devices upon joining.
-uint8 zgPreConfigKeys = FALSE;// TRUE;
+uint8 zgPreConfigKeys = TRUE;// TRUE;
 
 // If true, defaultTCLinkKey should be configured on all devices on the
 // network. If false, individual trust center link key between each device and
diff -urN ZStack-CC2530-2.5.1a.original/Components/stack/zcl/zcl_key_establish.c ZStack-CC2530-2.5.1a/Components/stack/zcl/zcl_key_establish.c
--- ZStack-CC2530-2.5.1a.original/Components/stack/zcl/zcl_key_establish.c	2012-04-02 17:02:18.000000000 +0300
+++ ZStack-CC2530-2.5.1a/Components/stack/zcl/zcl_key_establish.c	2013-06-04 13:07:59.228606003 +0300
@@ -1448,7 +1448,10 @@
   // Key Establishment Procedure complete. Restore the saved poll rate for end device
   NLME_SetPollRate(zclSavedPollRate);
 #endif
-  return ZCL_STATUS_CMD_HAS_RSP;
+  if (status != TermKeyStatus_Success) 
+    return ZCL_STATUS_CMD_HAS_RSP;
+  else 
+    return ZSuccess;
 }
 
 /*********************************************************************
diff -urN ZStack-CC2530-2.5.1a.original/Components/stack/zcl/zcl_key_establish.h ZStack-CC2530-2.5.1a/Components/stack/zcl/zcl_key_establish.h
--- ZStack-CC2530-2.5.1a.original/Components/stack/zcl/zcl_key_establish.h	2012-04-02 17:02:18.000000000 +0300
+++ ZStack-CC2530-2.5.1a/Components/stack/zcl/zcl_key_establish.h	2013-06-18 15:50:11.329439020 +0300
@@ -61,7 +61,7 @@
 #define KEY_ESTABLISHMENT_REC_AGING_EVT                 0x01
 #define KEY_ESTABLISHMENT_CMD_PROCESS_EVT               0x02
 #define KEY_ESTABLISHMENT_RSP_PROCESS_EVT               0x04
-#define KEY_ESTABLISHMENT_REC_AGING_INTERVAL            1000  // in ms
+#define KEY_ESTABLISHMENT_REC_AGING_INTERVAL            10000  // in ms
 #define KEY_ESTABLISHMENT_WAIT_PERIOD                   500
 
 // Key Establishment Cluster Attributes
Binary files ZStack-CC2530-2.5.1a.original/Projects/zstack/Libraries/TI2530DB/bin/ecc.r51 and ZStack-CC2530-2.5.1a/Projects/zstack/Libraries/TI2530DB/bin/ecc.r51 differ
diff -urN ZStack-CC2530-2.5.1a.original/Projects/zstack/Tools/CC2530DB/f8wConfig.cfg ZStack-CC2530-2.5.1a/Projects/zstack/Tools/CC2530DB/f8wConfig.cfg
--- ZStack-CC2530-2.5.1a.original/Projects/zstack/Tools/CC2530DB/f8wConfig.cfg	2013-06-26 16:40:16.778189133 +0300
+++ ZStack-CC2530-2.5.1a/Projects/zstack/Tools/CC2530DB/f8wConfig.cfg	2013-06-18 15:47:45.816522446 +0300
@@ -18,7 +18,7 @@
 -DZIGBEEPRO
 
 /* Set to 0 for no security, otherwise non-0 */
--DSECURE=0
+-DSECURE=1
 -DZG_SECURE_DYNAMIC=0
 
 /* Enable the Reflector */
diff -urN ZStack-CC2530-2.5.1a.original/Projects/zstack/ZNP/Source/znp.cfg ZStack-CC2530-2.5.1a/Projects/zstack/ZNP/Source/znp.cfg
--- ZStack-CC2530-2.5.1a.original/Projects/zstack/ZNP/Source/znp.cfg	2012-03-29 12:09:02.000000000 +0300
+++ ZStack-CC2530-2.5.1a/Projects/zstack/ZNP/Source/znp.cfg	2013-06-26 16:33:40.746960102 +0300
@@ -72,7 +72,7 @@
 //-DMAX_RTG_SRC_ENTRIES=100
 
 // Define this flag to enable ZNP implementation of the ZCL_KEY_ESTABLISHMENT_ENDPOINT and task.
-//-DTC_LINKKEY_JOIN
+-DTC_LINKKEY_JOIN
 
 /*
  * Monitor Test Interface

    Of course, if you still think it might be helpful, I can try porting the SampleApp IPD for our device as well and see what happens. But at this point, I don't really see how this issue could have followed from anything that we have done on top of vanilla zstack.

  • 0 in reply to Ville Paukkonen

    Hi everybody,

    I just returned to work after my summer vacation, and I'm still stuck on this same issue. I have now stripped all but one of the remaining patches from the ZNP code, so that the hex image was generated as follows:

    1. I downloaded and unpacked swrc126g.zip and run the extracted ZStack-CC2530-2.5.1a.exe

    2. I opened the project file "C:\Texas Instruments\ZStack-CC2530-2.5.1a\Projects\zstack\ZNP\CC253x\znp.eww" with IAR Embedded Workbench for 8051 IDE (version 8.20.1, common components version 6.4.6.2419)

    3. I manually modified zcl_key_establish.c so that zclGeneral_ProcessInCmd_ConfirmKeyRsp() returns ZSuccess on success instead of ZCL_STATUS_CMD_HAS_RSP. This modification is essential in order to complete CBKE with test harness, and since it only replaces one constant with another in a part of the code which is only executed once during CBKE, it is very unlikely to cause any unrelated side effects.

    4. I selected the "CC2530 - TestHex" configuration, ran Project > Make and flashed the resulting CC2530ZNP-Test.hex on a CC2530 chip using SmartRF Flash Programmer and a CC Debugger.

    After this, when I use this chip as the ZNP on a device that uses a separate ARM based application processor (and these two communicate over UART), the conformance test cases that involve ZCL Read Attribute commands being sent from the test harness to our device fail randomly in the way described in the first message of this thread. For example, when the test harness sends a ZCL Read Attribute command for attribute 0x0003 in cluster 0x000A, the device under test sometimes replies with a ZCL Read Attribute response that only contains the information that attribute 0x0005 is not supported in that cluster. Or, when the test harness sends ZCL Read Attribute command for attribute 0x0000 in cluster 0x0000, the device under test replies with a response that contains the value of attribute 0x0005 in that cluster.

    At this point I am completely out of ideas regarding what else I could still try. It seems extremely likely to me that this issue is either an actual ZStack bug, or possibly a glitch in the IAR Embedded Workbench, since I believe I have eliminated all other possibilities quite exhaustively. But on the other hand, this seems like such an elementary use case that it is hard to believe that nobody else has encountered this before.

    This is essentially the last issue that we need to sort out in order to get our product certified by ZigBee alliance, so we need to find some sort of solution or workaround as soon as possible. All ideas are appreciated.

    - Ville