• Locked Locked
  • Replies 2 replies
  • Subscribers 55 subscribers
  • Views 577 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.

ZDApp.c change of behaviour from ZStack v1.4.2 to v1.4.3 ??

Carlos3604
Prodigy 40 points
Other Parts Discussed in Thread: CC2430

 I have just updated from 1.4.2 to 1.4.3 ZStack for CC2430.

  The ZDApp_event_loop, after the joining sequence sends a NLME_joinRequest,  was catching the ZDO_NWK_JOIN_IND event in ZDApp_ProcessOSALMsg and appropriately calling   ZDApp_ProcessNetworkJoin() to change the devState etc...my new version doesnt seem to do this anymore! Consequently,  the devState stays as DEV_NWK_JOIING. More seriously, a router  never gets the chance to call NLME_StartRouterRequest() and so defaults to behave like an end device!

 Its likely I have missed something will upgrading. Has anyone encountered the same problem? The call to ZDApp_event_loop is hidden in the library code as I assume it comes straight from the NWK layer. I have checked my library files and they all seem to be exactly the same as what was included in the 1.4.3 download. My project points to the new libraries too. I have also ensured that I erase the flash when I upload the code. Any ideas?

Thanks 

  • Prodigy 40 points

    Ok,

    So I looked a little deeper and discovered that the function ZDO_JoinConfirmCB() is what gets called from the layer below, and this in turn calls ZDApp_ProcessNetworkJoin(). I had commented out the HALledset line but not the "else" so it was always skipping the call to ZDApp_ProcessNetworkJoin()....doh! 

    Beware of #ifdef statments!

     Carl.

  • in reply to Carlos3604
    TI__Expert 4155 points

    Nice catch Carl, but the rejoin feature was not designed to be used by routers. Actually routers never need to rejoin the network. They can always keep their short address by using NV_RESTORE compile option. This will make sure that the router keeps the associated device list and any binding entries after a power cycle too.

    The NWK rejoin request/response mechanism should only be used with end devices.

    Note however, that recently there was a bug discovered with the rejoin process. If an end device joins too many routers, it's neighbor table becomes full and it won't kick off the rejoin process. To fix this you have to patch the end devices in your networks by replacing ZDO_SyncIndicationCB() [in ZDApp.c] with the following:
     
    void ZDO_SyncIndicationCB( byte type, uint16 shortAddr )
    {
     
    #if !defined ( RTR_NWK )
        if ( type == 1 )
        {
          ZDApp_SendMsg( ZDAppTaskID, ZDO_NWK_JOIN_REQ, sizeof(osal_event_hdr_t),
    NULL );
         
          // We are doing a rejoin, so clear the neighbor table
          nwkNeighborInitTable();
        }
    #endif
      return;
    }

    If you're using the 1.4.2 version, then you'll have to separately define the following:

      *********************************************************************  * @fn          nwkNeighborInitTable  *  * @brief       Initializes the entire table.  *  * @param       none  *  * @return      none  */ void nwkNeighborInitTable( void ) {   uint8 i;   for ( i = 0; i < gMAX_NEIGHBOR_ENTRIES; i++ )   {     nwkNeighborClearEntry( &neighborTable[i] );   } }   /*********************************************************************  * @fn          nwkNeighborClearEntry  *  * @brief       Clear the neighbor table entry that is passed in.  *  * @param       entry - entry to clear  *  * @return      none  */ void nwkNeighborClearEntry( neighborEntry_t *entry ) {   if ( entry )   {     osal_memset( entry, 0x00, sizeof ( neighborEntry_t ) );     entry->neighborAddress = INVALID_NODE_ADDR;     entry->panId = INVALID_PAN_ID;  } }