• State
  • Locked Locked
  • Replies 8 replies
  • Subscribers 58 subscribers
  • Views 3253 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.

NWK Leave commands ignored?

Voon Wong
Intellectual 295 points

Other Parts Discussed in Thread: Z-STACK

Hi,

I'm using ZStack 2.4.0 to build ZigBee Smart Energy devices and have used the IPD example as my baseline.  When my ESP sends a NWK Leave command: NWK Command Frame ID = 0x04 Leave with payload 0x60 (rejoin=1, request=1, remove children=0), I expected ZDO_LeaveInd( NLME_LeaveInd_t* ind ); in ZDApp.c to be called, and I can take appropriate action.  Indeed the comments say "This function allows the next higher layer of a device to be notified of a remote leave request or indication".

However, searching through the source code, this function appears never to be called.  Further, breakpoints placed in this function is never triggered, suggesting that it was never called, even as my ESP repeatedly sends the NWK Leave command.

How do I ensure that a NWK Leave command from the ESP actually triggers an event on the IPD?  Thanks.

Voon

  • 0
    TI__Expert 4155 points

    Are you sending it as a broadcast or unicast to the IPD?

  • 0 in reply to "Double 0"
    Intellectual 295 points

    Good point, it's a broadcast.  Thanks for the insight!

    I'll try sending a unicast NW_LEAVE instead.

    Voon

  • 0 in reply to Voon Wong
    Intellectual 295 points

    I haven't visited this in a while, hence the lack of updates.  I'm looking at it again now and am finding that even with unicast, ZDO_LeaveInd() never gets called.  What can I do?

  • 0 in reply to Voon Wong
    TI__Expert 4155 points

    Hi Voon, can you mention the exact code that you are using? I can try to replicate the issue.

  • 0 in reply to "Double 0"
    Intellectual 295 points

    Hi Double 0,

    Thanks for looking into this.  I'm still baffled as to why the ESP actually sends the leave request in the first place.  It seems to happen only in extreme corner-cases when certain packets are lost and the exchange of packets are unexpected.  This even happens with a NTS (National Technical Systems) test harness (used as an ESP), which we're using for certification (and are using only as a black box).

    Here's an example leave packet sent to the IPD.

    [16:13:36.877122]    NWK: Leave    61 88 32 9D 9B 04 68 00 00 09 12 04 68 00 00 01 24 01 00 A6 DD B7 C0 03 D1 28 16 50 00 00 01 00 A6 DD B7 C0 03 D1 00 04 60 5D 9D EB E8 00 00
        Frame Information : ZigBee, C20, L47, -76dbm
            Packet Number: 385
            Protocol: ZigBee
            Timestamp: 16:13:36.877122
            Time Delta: 00:00:00.002400
            Channel: 20
            Length: 47
            Link Quality: -76dbm
        MAC Header
            Frame Control: 0x8861
                .... .... .... .001 Frame Type: [0x1] Data
                .... .... .... 0... Security Enabled: [0x0] Disable
                .... .... ...0 .... Frame Pending: [0x0] No More Data
                .... .... ..1. .... Ack Request: [0x1] Acknowledgement Requiered
                .... .... .1.. .... Intra-Pan: [0x1] within the pan
                .... ..00 0... .... reserved: 0x0
                .... 10.. .... .... Destination Addressing Mode: [0x2] 16-bit short address
                ..00 .... .... .... reserved: 0x0
                10.. .... .... .... Source Addressing Mode: [0x2] 16-bit short address
            Sequence Number: 0x32
            Dest. PAN Ident.: 0x9B9D
            Dest. Address: 0x6804
            Source Address: 0x0000
        NWK Header
            Frame Control: 0x1209
                .... .... .... ..01 Frame Type: [0x1] NWK Command
                .... .... ..00 10.. Protocol Version: 0x2
                .... .... 00.. .... Discovery Route: [0x0] Supress route discovery
                .... ...0 .... .... Multicast Flag: [0x0] Unicast or Broadcast
                .... ..1. .... .... Security Enabled: [0x1] True
                .... .0.. .... .... Source Route Included: [0x0] False
                .... 0... .... .... Destination IEEE Address Included: [0x0] False
                ...1 .... .... .... Source IEEE Address Included: [0x1] True
                000. .... .... .... reserved: 0x0
            Destination Address: 0x6804
            Source Address: 0x0000
            Radius: 0x01
            Sequence Number: 0x24
            Source IEEE Address: 0xD103C0B7DDA60001
        NWK Aux Header
            NWK Security Control: 0x28
                .... .000 NWK Security Level: [0x0] None
                ...0 1... Key NWK Identifier: [0x1] Network key
                ..1. .... Extended Nonce: [0x1] True
                00.. .... reserved: 0x0
            NWK Frame Counter: 0x00005016
            Source Address: 0xD103C0B7DDA60001
            NWK Key Seq Number: 0x00
        NWK Payload
            NWK Command Frame ID: [0x04] Leave
            NWK Command Payload
                Leave Options: 0x60
                    ...0 0000 reserved: 0x0
                    ..1. .... Rejoin: 0x1
                    .1.. .... Request: 0x1
                    0... .... Remove Children: 0x0
        NWK MIC: 0xE8EB9D5D
        MAC Footer
            Frame Check Sequence: 0x0000
        NWK Key : 12:33:33:33:33:33:33:33:33:33:33:33:33:33:33:33

    Tracing through the binary parts of Z-stack, I've found that the error is most likely at NLME_LeaveCmdProcess which does get called, but returns without calling ZDO_LeaveInd.  I do have a best-guess hand-decompiled C-source for this function, but I don't want to violate any EULAs so I won't post it here; I'm sure you have the real source anyway.

    NLME_LeaveCmdProcess:
     012F7A    153B               pushm.w #4,R11
     012F7C    8031 000E          sub.w   #0xE,SP
     012F80    4C4A               mov.b   R12,R10
     012F82    4D0B               mov.w   R13,R11
     012F84    403E 000E          mov.w   #0xE,R14
     012F88    434D               clr.b   R13
     012F8A    410C               mov.w   SP,R12
     012F8C    13B1 FBAA          calla   #osal_memset
     012F90    4B1F 001E          mov.w   0x1E(R11),R15
     012F94    4F5E 0001          mov.b   0x1(R15),R14
     012F98    B07E 001F          bit.b   #0x1F,R14
     012F9C    2404               jeq     0x12FA6
     012F9E    13B1 2A06          calla   #0x12A06
     012FA2    434C               clr.b   R12
     012FA4    3C33               jmp     0x1300C
     012FA6    B07E 0020          bit.b   #0x20,R14
     012FAA    2802               jnc     0x12FB0
     012FAC    43D1 000C          mov.b   #0x1,0xC(SP)
     012FB0    934E               tst.b   R14
     012FB2    3402               jge     0x12FB8
     012FB4    43D1 000B          mov.b   #0x1,0xB(SP)
     012FB8    B07E 0040          bit.b   #0x40,R14
     012FBC    2803               jnc     0x12FC4
     012FBE    43D1 000A          mov.b   #0x1,0xA(SP)
     012FC2    3C03               jmp     0x12FCA
     012FC4    93D1 000A          cmp.b   #0x1,0xA(SP)
     012FC8    2003               jne     0x12FD0
     012FCA    4B1D 0014          mov.w   0x14(R11),R13
     012FCE    3C02               jmp     0x12FD4
     012FD0    4B1D 0016          mov.w   0x16(R11),R13
     012FD4    410C               mov.w   SP,R12
     012FD6    13B1 312E          calla   #0x1312E
     012FDA    4B91 000C 0000     mov.w   0xC(R11),0x0(SP)
     012FE0    93D1 000A          cmp.b   #0x1,0xA(SP)
     012FE4    200F               jne     0x13004
     012FE6    13B1 2C34          calla   #0x12C34
     012FEA    200F               jne     0x1300A
     012FEC    13B1 2170          calla   #NLME_GetCoordShortAddr
     012FF0    9C8B 000C          cmp.w   R12,0xC(R11)
     012FF4    200A               jne     0x1300A
     012FF6    13B1 3126          calla   #0x13126
     012FFA    410C               mov.w   SP,R12
     012FFC    532C               incd.w  R12
     012FFE    13B1 3014          calla   #0x13014
     013002    2403               jeq     0x1300A
     013004    410C               mov.w   SP,R12
     013006    13B0 8856          calla   #ZDO_LeaveInd
     01300A    4A4C               mov.b   R10,R12
     01300C    0180 27C4          bra     #0x127C4
     013010    403C 1F25          mov.w   #0x1F25,R12
     013014    13B1 F2D4          calla   #sAddrExtCmp
     013018    934C               tst.b   R12
     01301A    0110               reta

  • 0 in reply to Voon Wong
    Prodigy 180 points

    Hello Voon

         I'am using Packet Sniffer to capture the frames. But I could't find the detail data as yours.Can you tell me how to find the detail data file of Packet Sniffer.

    I want to know how to saw the data above.Thank you!

    bin

  • 0 in reply to Voon Wong
    Prodigy 10 points

    Voon,

    Did you ever resolve this issue?  I'm seeing the same problem in Z-Stack Home 1.2.  Reading in the Z-Stack Core release notes there was one fix : 

    [5057] Modified 'ZDO_LeaveInd()' to not send a "Leave Response" message
    if the device is going to "rejoin" the network.

    but that is not the issue here, but it implies that the function does get called.  I have set breakpoints in ZDO_LeaveInd() but they are never hit.

    Thanks,

    -- Ken

  • 0 in reply to bin liu1
    Expert 1395 points

    TI Packet Sniffer has limited features. Use Ubiqua from Ubilogix, for example.