• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 54 subscribers
  • Views 519 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.

Z-Stack Lighting release 1.0.0 Typo Error

LAKSHMANAN KUMAR RANGARAJ
Expert 1795 points
Other Parts Discussed in Thread: PMP

Dear TI,

  I found the typo error in the zll_initiator.c function in the latest TI ZLL release.

 

/*********************************************************************  

* @fn      initiatorSetNwkToInitState  

*  

* @brief   Set our network state to its original state.  

*

 * @param   void  

*  

* @return  void  

*/

 static void initiatorSetNwkToInitState()

{  

 // Turn MAC receiver back to its old state  

 ZMacSetReq( ZMacRxOnIdle, &savedRxOnIdle );

  // Tune back to our channel  

 zll_SetChannel( _NIB.nwkLogicalChannel );

  // Set NWK task to run  

nwk_setStateIdle( FALSE );

  if ( savedPollRate != zgPollRate )  

  {    

     NLME_SetPollRate( savedPollRate );    

      savedPollRate = POLL_RATE;   }

  if ( savedQueuedPollRate != zgQueuedPollRate )  

{    

NLME_SetQueuedPollRate( savedQueuedPollRate );    

savedQueuedPollRate = QUEUED_POLL_RATE;  

 }

  if ( savedResponsePollRate != savedResponsePollRate )    // if ( savedResponsePollRate != zgResponsePollRate)

 {     NLME_SetResponseRate( savedResponsePollRate );    

 savedResponsePollRate = RESPONSE_POLL_RATE;   }

  // In case we've lost our parent   ZDApp_StartJoiningCycle();

 }

savedResponsePollRate != zgResponsePollRate

Its a very simple type error. but this error wont let the Server send the response to the client.For example,take 2 servers(light,target) and 1 client(remote control,initiator)

1.Do the touch link for the first device -->light(server 1,Target)

2.after successful connection. Do the touch link for the second device --->light(server 2,Target)

3.In the Ti Stack Flow --> Initiator (client,remote) -->will do the initiatorSendNwkJoinReq() -> router join req -->which in turn will trigger the initiatorSetNwkToInitState() function after the touch link success.

 

In a very simple way, WE WONT SENDTHE Data Req from the Initiator to get the information from server(router, target)

Spend 2 days to find the root cause of this bug.

Thanks and Regards

Lakshman,PMP,PMI-RMP

 

 

 

 

  • 0
    TI__Genius 9180 points

    Lakshman,

        Thank you for spending the time finding this issue, you are correct there is a typo and I will see it is fixed in our next release.

    However I do not see how this is causing the issues you have reported, I tried the test case you mention, which is the same case myself and many others have tested before making this release and I do not see this causes a big issues during the touchlink process. Which message are you expecting when you state "WE WONT SENDTHE Data Req from the Initiator to get the information from server(router, target)"? Can you provide a packet trace of the issue that you are seeing?


    Regards,

    TC.

  • 0 in reply to TopCat
    Expert 1795 points

    Dear TopCat,

      Yes, it bit difficult to trace this bug.

     Precondition : we need to test the scenario with 2 server and 1 client.If you test with 1 server and 1 client.you wont see any issue.  Since we are using 2 profiles in ZLL . One during commissioning process Light Link Profile(0xC05E) and another one is Home automation profile(0x0104).  So issue will happen during the HA ZCL Message transfer.

    Please follow the ZLL Test Specific "TP-CST-TC-03: Group addressed commands with server as DUT"

    Abbrevations:

    TH-->Test harness/Golden Unit ( You can use normal client).

    DUT -->Device Under Test.

    Test Preparation:

    1.Power on TH CLIENT and DUT SERVER1.   

          After:TH CLIENT and DUT SERVER1 are powered on.

    2.With TH CLIENT held close to DUT SERVER1, TH CLIENT touchlinks with DUT SERVER1.Touchlink should succeed.

     After: Observe touchlinking command frames between TH CLIENT and DUT SERVER1.

    3.TH CLIENT sends a remove all groups command to DUT SERVER1.

    After:TH CLIENT unicasts a ZCL remove all groups command frame to DUT SERVER1.

    4.TH CLIENT sends an add group command to add DUT SERVER1 to group 1.

    After:TH CLIENT unicasts a ZCL add group command frame to DUT SERVER1, with the group ID field set to 0x0001. DUT SERVER1 unicasts a ZCL add group response command frame to TH CLIENT.

     5.Power on DUT SERVER2.

    After:DUT SERVER2 is powered on.

    6. Conditional on step 5 being invoked:With TH CLIENT held close to DUT SERVER2, TH CLIENT touchlinks with DUT SERVER2.Touchlink should succeed.

    After:Observe touchlinking command frames between TH CLIENT and DUT SERVER2.

     7.Conditional on step P5 being invoked:TH CLIENT sends a remove all groups command to DUT SERVER2.

     After:TH CLIENT unicasts a ZCL remove all groups command frame to DUT SERVER2.

    8.Conditional on step P5 being invoked:TH CLIENT sends an add group command to add DUT SERVER2 to group 1.

    After:TH CLIENT unicasts a ZCL add group command frame to DUT SERVER2, with the group ID field set to 0x0001.DUT SERVER2 unicasts a ZCL add group response command frame to TH CLIENT.

    Test Procedure:

    1.TH CLIENT sends an on command to group 1.

     Verification:TH CLIENT broadcasts a ZCL on command frame to group ID 0x0001.DUT SERVER1 should turn on. Conditional on step 5 being invoked: DUT SERVER2 should turn on.

    2.TH CLIENT sends an off command to group 1.

    Verification:TH CLIENT broadcasts a ZCL off command frame to group ID 0x0001. DUT SERVER1 should turn off.Conditional on step 5 being invoked: DUT SERVER2 should turn off.

    3.TH CLIENT sends a toggle command to group 1.

    Verification:TH CLIENT broadcasts a ZCL toggle command frame to group ID 0x0001. DUT SERVER1 should turn on.Conditional on step P5 being invoked: DUT SERVER2 should turn on.

    4.TH CLIENT sends a read attributes command to DUT SERVER1 to read the OnOff attribute.

    Verification:TH CLIENT unicasts a ZCL read attributes command frame for the OnOff attribute to DUT SERVER1. DUT SERVER1 unicasts a ZCL read attributes response command frame to TH CLIENT. OnOff attribute has the value 0x01.

    5.Conditional on step 5 being invoked:TH CLIENT sends a read attributes command to DUT SERVER2 to read the OnOff attribute.

    Verification:TH CLIENT unicasts a ZCL read attributes command frame for the OnOff attribute to DUT SERVER2. DUT SERVER2 unicasts a ZCL read attributes response command frame to TH CLIENT.OnOff attribute has the value 0x01.

    6.TH CLIENT sends a toggle command to group 1.

    Verification:TH CLIENT broadcasts a ZCL toggle command frame to group ID 0x0001.DUT SERVER1 should turn off. Conditional on step 5 being invoked: DUT SERVER2 should turn off.

    7.TH CLIENT sends a read attributes command to DUT SERVER1 to read the OnOff attribute.

    Verification:TH CLIENT unicasts a ZCL read attributes command frame for the OnOff attribute to DUT SERVER1. DUT SERVER1 unicasts a ZCL read attributes response command frame to TH CLIENT.OnOff attribute has the value 0x00.

    8.Conditional on step 5 being invoked:TH CLIENT sends a read attributes command to DUT SERVER2 to read the OnOff attribute.

    Verification:TH CLIENT unicasts a ZCL read attributes command frame for the OnOff attribute to DUT SERVER2. DUT SERVER2 unicasts a ZCL read attributes response command frame to TH CLIENT. OnOff attribute has the value 0x00.

    Step 7 in Test procedure:we wont get the Read Attribute Response.

    Message transfer before fixing the Typo Error.  

    Client  -----Read(ON/OFF)Attribute ---------> Server1  

    Client  <----- MAC Ack ---------------------  Server1    

    Correct message transfer  after fixing the Typo error.  

    Client  -----Read(ON/OFF)Attribute ---------> Server1  

    Client  <----- MAC Ack ---------------------  Server1  

    Client  ---- Data Req ----------------------> Server1  

    Client  <------Ack -------------------------  Server1  

    Client  <----Read Response(ON/OFF)Attribute-- Server1  

    Client  ------ MAC Ack ---------------------> Server1

     Hope it helps. if you need further packet trace. feel free. I will capture and send it to you.

    Thanks and Regards

    Lakshman,PMP,PMI-RMP

     

  • 0 in reply to LAKSHMANAN KUMAR RANGARAJ
    TI__Genius 9180 points

    Dear Lakshman,

        Thank you for the clarification and your efforts, indeed you are correct. In this case it is the TH that is the device that exhibits the behavior  I don't recall there being a similar test case for the DUT, or we would have seen this issue during our certification.

    We do not recommend making changes to the profile layer as this could cause issues in certifying your product, but in this case the fix is isolated and obviously the intent of the developer.

    This is a bigger issue when the ZllRemote is a sleeping end device, polling enddevices will eventually get the read rsp during there periodic poll, so this may not be as much as an issue depending on the POLL_RATE defined in fw8config.cfg. This fix as suggested earlier in this thread is:

    /*********************************************************************  

    * @fn      initiatorSetNwkToInitState  

    *  

    * @brief   Set our network state to its original state.  

    *

     * @param   void  

    *  

    * @return  void  

    */

    static void initiatorSetNwkToInitState()

    {  

     ...

      //if ( savedResponsePollRate != savedResponsePollRate ) 

      if ( savedResponsePollRate != zgResponsePollRate )
      {

        NLME_SetResponseRate( savedResponsePollRate );    

        savedResponsePollRate = RESPONSE_POLL_RATE;   

      }

    ...

    }


    This well be fixed in our next release.

    /TC.