• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 54 subscribers
  • Views 672 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 light link 1.0.1-bug reopened in latest release -

LAKSHMANAN KUMAR RANGARAJ
Expert 1795 points

Other Parts Discussed in Thread: PMP

Dear TI/TopCat,

 The Bug reported in http://e2e.ti.com/support/low_power_rf/f/158/p/248017/869835.aspx#869835

reponed in latest release 1.0.1  the fix mentioned below not working

void zll_InitVariables( bool initiator )

{  

zllTransID = 0;  

zllJoinedHANetwork = FALSE;

  if ( zll_IsFactoryNew() )  

{    

_NIB.nwkDevAddress = INVALID_NODE_ADDR;  

 }  

else  

{    

if ( zgTrustCenterAddr == NWK_PAN_COORD_ADDR )    

 {      

zllJoinedHANetwork = TRUE;    

}  

}

  // verify groups communication is initiated by broadcasts rather than multicasts  

_NIB.nwkUseMultiCast = FALSE;  

 // detect and remove stored deprecated end device children after power up  

// zgRouterOffAssocCleanup = TRUE;  ---> bug reopened

// osal_nv_write(ZCD_NV_ROUTER_OFF_ASSOC_CLEANUP, 0, sizeof(zgRouterOffAssocCleanup), &zgRouterOffAssoc

}

The correct bug fix might be

in ZGlobal.c

// Cleanup Child Table according to routing traffic uint8

 zgRouterOffAssocCleanup =TRUE ;//FALSE

 

Please confirm the bug fix.

 

Thanks and Regards

Lakshman,PMP,PMI-RMP

  • 0
    TI__Genius 9180 points

    Lakshman,

        Sorry for the delay in response. I am not sure what happened here, looking at our bug tracking system the bug fix was verified and the target release was 1.0.1. I am checking now if the final fix made it in to the release. Bug 4960 is the bug number and I do not see this in the release notes, so maybe it did not make it into the release.

    The fix you propose above will be ok for you. But as this may not be wanted by all customers we default to not having this enabled and leave it to the application or profile to define. As this will always be required in ZLL we will enable it in the profile.

    Tony.

  • 0 in reply to TopCat
    Expert 1795 points

    Tony,

     Thanks for the reply. Actually if we wont have the fix mentioned above. We wont get the read attribute response from other device.meaning will end up in failing the ZLL spec. We already discussed about this in \

    http://e2e.ti.com/support/low_power_rf/f/158/p/248017/869835.aspx#869835

     Thanks for confirming the bug fix.

    Regards

    Lakshman,PMP,PMI-RMP

  • 0 in reply to LAKSHMANAN KUMAR RANGARAJ
    TI__Genius 9180 points

    Lakshman,

        I have done some further testing and the issue I saw yesterday was only down to the RouteReq required to setup the new route, after this the read rsp is sent successfully. Can you re-check you findings? I find that in my testing the issue you mentioned has been resolved.

    I see that changing the following has no effect on the test:

    in ZGlobal.c

    // Cleanup Child Table according to routing traffic uint8

     zgRouterOffAssocCleanup =TRUE ;//FALSE

    Regards,

    TC.

  • 0 in reply to TopCat
    Expert 1795 points

    Hi Tony,

       Thanks for testing the issue.when i tested 1 month back. i found request response not coming from one of the light. So i raised as an issue.

    I agree that we do zgRouterOffAssocCleanup =TRUE. The question is whether in ZGlobal.c or in zll_InitVariables( bool initiator ).

     I am unable to reproduce the issue. You are right . i agree with you it wont make any difference if we call it in inside function or globally.

    Thanks for your effort and continous support.

    Thanks and Regards

    Lakshman,PMP,PMI-RMP