• State TI Thinks Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 1 answer
  • Subscribers 57 subscribers
  • Views 627 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.

CC2652R: ZED cannot always rejoin to coordinator

Walter Macamos
Genius 5345 points
Part Number: CC2652R
Other Parts Discussed in Thread: CC2538

Hi Ti Team,

We observed that our ZED with  source addr=0xce97 cannot  consistently re-join after power cycle.

 It can re-join after several power cycles or several re-join retries.

 

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/158/unable-to-rejoin-aftwr-power-cycle-sourceaddr0xce97-2020_2D00_mar_2D00_16_2D00_330pm.7z The sniffer log is attached for your analysis.

Regards,

Walter

  • 0
    Guru 735695 points

    What is SDK version on your ZED and what's your coordinator?

  • 0 in reply to YiKai Chen
    Genius 5345 points

    Hi YK,

    CC2652 ZED SDK 3.10

    CC2538 ZC  SDK 3.0.2

    Regards,

  • 0 in reply to Walter Macamos
    TI__Mastermind 25850 points

    Hi Walter,

    Do you observe the following behavior with other ZEDs? How many ZEDs are in the network?

    Would it be possible for you to try to use a different device as the coordinator instead of the CC2538 and see if the same behavior occurs?

    Best Regards,

    Marlyn

  • 0 in reply to Marlyn Rosales Castaneda20
    Genius 5345 points

    Hi Marlyn,

    Same behavior with other ZEDs. Even if 1 ZED only this problem persists.

    We do not have other coordinator and also want to fix our own cc2538 issues. 

    There is another issue where one device keeps sending Permit Join Request. Any explanation for this? Please check the snapshot and the sniffer log.

    https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/158/some-device-always-send-permit-join-request-source_3D00_7d84.png.pcapng.7zRegards,

    Walter

  • 0 in reply to Walter Macamos
    TI__Mastermind 25850 points

    Walter,

    Walter Macamos said:
    Same behavior with other ZEDs.

    Could you please check the relevant association table/s when a ZED tries to rejoin to see if it is still associated?

    Walter Macamos said:
    There is another issue where one device keeps sending Permit Join Request

    Have you reset and re-flashed the device?

    I am not able to open the sniffer log you attached, the extension might be different than from what was intended. Could you please try to re-link?

    Best Regards,

    Marlyn

  • 0 in reply to Walter Macamos
    TI__Guru**** 219997 points

    Walter,

    Please provide smaller or partial sniffer logs as these are very large and therefore difficult to filter through.  Based on the inhospitable channel, with the large number of devices and networks communication, it becomes difficult for the ZC to send MAC ACKs or Rejoin Responses to the ZED.  Focus on debugging your ZC.

    Regarding the Permit Join Requests, the ZED retries if not receiving a MAC ACK but otherwise appears to be transmitting on a 3-second timer.

    Regards,
    Ryan 

  • 0 in reply to Ryan Brown1
    Genius 5345 points

    Hi Ryan,

    Rejoin now OK after adding this:

    1. We increased the NWK_FRAMECOUNTER_CHANGES_RESTORE_DELTA  from 250 to 1000 based from https://e2e.ti.com/support/wireless-connectivity/zigbee-and-thread/f/158/p/890135/3291505#3291505

    2.  We added this -- from https://e2e.ti.com/support/wireless-connectivity/zigbee-and-thread/f/158/p/808476/3040533

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    void ZDApp_RestoreNwkSecMaterial(void)
    {
      uint8 Found = FALSE;
      uint8 i;
      nwkSecMaterialDesc_t nwkSecMaterialDesc;
      uint8 UpdateFrameCounter = FALSE;
      //Search if we do have security material for this network
      for( i = 0; i < gMAX_NWK_SEC_MATERIAL_TABLE_ENTRIES; i++)
      {
        osal_nv_read(ZCD_NV_NWK_SEC_MATERIAL_TABLE_START + i,0,sizeof(nwkSecMaterialDesc_t),&nwkSecMaterialDesc);
        {
          if(osal_memcmp(_NIB.extendedPANID,nwkSecMaterialDesc.extendedPanID,Z_EXTADDR_LEN))
          {
            UpdateFrameCounter = TRUE;
            Found = TRUE;
            break;
          }
        }
      }   
      //Check if we do have frame counter stored in the generic
      if(!Found)
      {
        //The last entry readed has the Generic item, thefore, no need to read it again
        if(nwkSecMaterialDesc.FrameCounter)
        {
          UpdateFrameCounter = TRUE;
          i--;                                                 <<<<<<--------- added this
        }
      } 
      if(UpdateFrameCounter && (!FrameCounterUpdated))
      {
        FrameCounterUpdated = TRUE;
        
        // Increment the frame counter stored in NV
        nwkSecMaterialDesc.FrameCounter += ( MAX_NWK_FRAMECOUNTER_CHANGES +
                                  NWK_FRAMECOUNTER_CHANGES_RESTORE_DELTA );
        
        nwkFrameCounter = nwkSecMaterialDesc.FrameCounter;
        
        osal_nv_write(ZCD_NV_NWK_SEC_MATERIAL_TABLE_START + i,0,sizeof(nwkSecMaterialDesc_t),&nwkSecMaterialDesc);
        
        nwkFrameCounterChanges = 0;
      }
      return;
    }
    Let me know if these changes are OK.
    Regards,
    Walter
  • 0 in reply to Walter Macamos
    TI__Guru**** 219997 points

    Yes, these changes are fine.  Thanks for providing your solution.

    Regards,
    Ryan