CC2652RSIP: Commissioning with a Green Power Device

Hi Christiane,

Does your Zigbee behavior follow any similarity to this E2E thread?  Please provide the specific SimpleLink F2 SDK version you are using.  Can you debug exactly which if statement condition causes the GP_SEC_RSP_DROP_FRAME return?

      if(((cmd.options.securityKeyRequest == TRUE) &&
      (gpDataInd->RxAfterTx == FALSE)) ||
      (cmd.options.securityKeyRequest == TRUE) &&
      (cmd.extOptions.securityLevel == GP_SECURITY_LVL_NO_SEC))
      {
        return GP_SEC_RSP_DROP_FRAME;
      }

You can attach the Wireshark capture by dragging/dropping the file directly into the reply box, click Insert -> Image/video/file, or provide a link to an online file share service.  I also recommend that you review the Green Power Application Overview section from the Z-Stack User's Guide.

Regards,
Ryan

Good morning Ryan,

Thanks for the quick reply.
Yes, I think that is exactly the problem.

I tried with SDK 3.40 and 7.10, I can see the same behavior with both SDK.

The exact flow is this:

File line 840: case zstackmsg_CmdIDs_GP_SECURITY_REQ

File gp_common.c line 937: gp_processSecRecMsg

                               line 703: GP_SecReq

File gp_sink.c: line 913: gp_SecurityOperationSink, 

                        line 943: status = ZInvalidParameter

                        line 1006: this if is true

                        line 1060: return with GP_SEC_RSP_DROP_FRAME

Unfortunately I can't attach the capture, when I try to drag and drop the file, nothing happens. I sent the file to Colombo Carlo.

Thanks again.

Please understand that TI provides the GP Sink application as an example, and as such the application layer for this feature is completely available and can be modified by developers to achieve their end product requirements.

With this in mind, use the Expression View inside the CCS debugger to determine the contents of gpDataInd, cmd, and gpsSecurityLevel.  Having these will help you further determine why none of the statements inside of the "line 1006 if statement" return GP_SEC_RSP_PASS_UNPROCESSED.  You can then add a custom else if statement to pass through the GP_CHANNEL_REQ_COMMAND_ID.

Since you have a working third-party sink and GP device system, and a working zc_thermostat_sink_CC26X2R1 and  gpd_temperaturesensor_CC26X2R1 example setup, you should be able to further analyze the Wireshark logs to replicate the third-party sink operation for your zc_thermostat_sink_CC26X2R1.

Is zclGp_GpCommissioningNotificationCommandCB never entered, even if you are able to get past the gp_SecurityOperationSink without the frame being dropped?

Regards,
Ryan

Hi Ryan,

sorry for the late reply.

I past the gp_SecurityOperationSink without drop the frame, now exits with GP_SEC_RSP_PASS_UNPROCESSED as you suggested. But never enters on zclGp_GpCommissioningNotificationCommandCB anyway.

Thanks,
Cristiane Bellenzier Piaia

Follow zclSampleThermostat_processAfIncomingMsgInd -> zcl_ProcessMessageMSG -> zclGp_HdlIncoming -> zclGp_HdlInSpecificCommands -> zclGp_ProcessInBasicCombo -> case COMMAND_GP_COMMISSIONING_NOTIFICATION to determine why pfnGpCommissioningNotificationCmd is not called or does not lead to zclGp_GpCommissioningNotificationCommandCB.

Regards,
Ryan

Hi Ryan,

thanks for the reply.

Because the zclSampleThermostat_processZStackMsgs never receive a pMsg->hdr.event = zstackmsg_CmdIDs_AF_INCOMING_MSG_IND.

Thanks,

Cristiane Bellenzier Piaia

Now that you've confirmed reception of the packet you are interested in, can you add the necessary application code for sending back a GP_CHANNEL_CCONFIG_COMMAND_ID using zcl_SendCommand?  You should be able to see the gpDataInd->GPDCmmdID from gp_SecurityOperationSink and perform what you need from there.  Reference zclGp_GpChannelRequestProcess for further details.

Regards,
Ryan

Hi Ryan,

thanks for the reply and for your suggestions.

I tried to do what you said but I can not see my package in the wireshark.

I'm include this code:

if(gp_SecRsp->Status == GP_SEC_RSP_PASS_UNPROCESSED)
{
    gp_DataInd_t *gpDataInd = NULL;
    gpDataInd = gp_DataIndGet(gp_SecReq->dGPStubHandle);

    if(gpDataInd->GPDCmmdID == GP_CHANNEL_REQ_COMMAND_ID)
    {
        afAddrType_t dstAddr;
        gpResponseCmd_t cmd;

        cmd.options = gpDataInd->appID;
        cmd.tempMasterShortAddr = _NIB.nwkDevAddress;

        if(GP_PAIRING_OPT_IS_APPLICATION_ID_GPD(gpDataInd->appID))
        {
            cmd.gpdSrcId = gpDataInd->SrcId;
        }
        else if(GP_PAIRING_OPT_IS_APPLICATION_ID_IEEE(gpDataInd->appID))
        {
            zcl_memcpy(cmd.gpdIEEE, gp_SecReq->gpdID.id.gpdExtAddr, Z_EXTADDR_LEN);
            cmd.ep = gp_SecReq->EndPoint;
        }

        cmd.cmdId = GP_CHANNEL_CCONFIG_COMMAND_ID;
        cmd.tempMasterChannel = _NIB.nwkLogicalChannel & 0x0F;
        cmd.payloadLen = sizeof(gpdChannelConfiguration_t);
        cmd.cmdPayload = zcl_mem_alloc(cmd.payloadLen);

        if (cmd.cmdPayload)
        {
            dstAddr.addr.shortAddr = _NIB.nwkDevAddress;

            dstAddr.addrMode = afAddr16Bit;
            dstAddr.endPoint = GREEN_POWER_INTERNAL_ENDPOINT;

            (*(gpdChannelConfiguration_t*)cmd.cmdPayload).operationalChannel = _NIB.nwkLogicalChannel - 11;
            (*(gpdChannelConfiguration_t*)cmd.cmdPayload).basic = TRUE;
            (*(gpdChannelConfiguration_t*)cmd.cmdPayload).reserved = 0;

            zclGp_SendGpResponseCommand(&dstAddr, &cmd);
            zcl_mem_free(cmd.cmdPayload);
        }
    }
}

in the 803 line from the gp_common.c file.

Do you have some suggestion? What I’m doing wrong?

Thanks,

Cristiane Bellenzier Piaia

Hi Cristiane,

Please put breakpoints at zclGp_SendGpResponseCommand and then zcl_SendCommand to make sure the code execution reaches these functions.  Then check the parameters of each to confirm that the packet being formatted has the correct information.  For example, _NIB.nwkDevAddress should be the local device's short address when I believe you want the dstAddr.addr.shortAddr to be the short address of the target GP device.

Regards,
Ryan

Hi Ryan,

Thank you very much your suggestions.

The good news is that now I can see my packet on Wireshark.

The bad news is, as you can see, my packet seen to be wrong, it is not a channel configuration as I expected.

This my code:

   if(gp_SecRsp->Status == GP_SEC_RSP_PASS_UNPROCESSED)
   {
       gp_DataInd_t *gpDataInd = NULL;
       gpDataInd = gp_DataIndGet(gp_SecReq->dGPStubHandle);

       if(gpDataInd->GPDCmmdID == GP_CHANNEL_REQ_COMMAND_ID)
       {
           afAddrType_t dstAddr;
           gpResponseCmd_t cmd;

           if(GP_PAIRING_OPT_IS_APPLICATION_ID_GPD(gpDataInd->appID))
           {
               cmd.gpdSrcId = gpDataInd->SrcId;
           }
           else if(GP_PAIRING_OPT_IS_APPLICATION_ID_IEEE(gpDataInd->appID))
           {
               zcl_memcpy(cmd.gpdIEEE, gp_SecReq->gpdID.id.gpdExtAddr, Z_EXTADDR_LEN);
               cmd.ep = gp_SecReq->EndPoint;
           }

           cmd.options = gpDataInd->appID;
           cmd.tempMasterShortAddr = gpDataInd->srcAddr.addr.shortAddr;
           cmd.tempMasterChannel = _NIB.nwkLogicalChannel & 0x0F;

           dstAddr.addr.shortAddr = gpDataInd->srcAddr.addr.shortAddr;
           dstAddr.addrMode = afAddr16Bit;
           dstAddr.endPoint = GREEN_POWER_INTERNAL_ENDPOINT;

           //command frame
           cmd.cmdId = GP_CHANNEL_CCONFIG_COMMAND_ID;
           cmd.payloadLen = sizeof(gpdChannelConfiguration_t);
           cmd.cmdPayload = zcl_mem_alloc( cmd.payloadLen );

           if (cmd.cmdPayload)
           {
               (*(gpdChannelConfiguration_t*)cmd.cmdPayload).operationalChannel = _NIB.nwkLogicalChannel - 11;
               (*(gpdChannelConfiguration_t*)cmd.cmdPayload).basic = TRUE;
               (*(gpdChannelConfiguration_t*)cmd.cmdPayload).reserved = 0;

               zclGp_SendGpResponseCommand(&dstAddr, &cmd);
               zcl_mem_free(cmd.cmdPayload);
           }
       }
   }

Thanks,

Cristiane Bellenzier Piaia

This appears to be some progress.  Please provide a sniffer log.  How does this packet compare against the operational setup version?  You've highlighted the NWK layer frame type, but this does not translate to the ZGP command.  You can also compare this packet against other GP command packets (listed in gp_common.h) to determine the disparity.  Is this packet using the correct security key and are you able to decrypt the data payload contents?

Regards,
Ryan

7271.test1.zip

Hi Ryan,

when I tried to attach the file as a pcapng file I received an error message, because this I changed the extension to a .zip.

To see the capture, change the extension to pcapng again.

Thanks,

Cristiane Bellenzier Piaia

Thanks, can you also provide the Zigbee NWK key (either join a regular Zigbee device to the network while sniffing the channel, or read from the NV information of the ZC/ZR).  Why is there no ZC (short address 0x0000) sending at least Link Status updates in your sniffer log?  Can you also provide the same of a working/complete setup sniffer log?

Regards,
Ryan

green_power_0x49.zip
Hi Ryan,

in attached you will find the capture with the sensor and other sink when the communication works fine (remember to change the extension to pcapng).

Regarding the zigbee nwk key, for now I'm using the default keys provide in the example.

Thanks.

Good morning Ryan.

with your suggestion, now I'm able to send the correct packet and receive the commissioning from the sensor. Thank you.

But I think I found a problem.

When I receive the commissioning package, in the gp_sink.c, function gp_processCommissioning, the len variable is increased only once but the data copied is larger causing a memory overflow as you can see in the video attached.

I think the problem is in this part:

this statement when the length is increased:

if((pCommissioningCmdPayload->options.securityKeyRequest == TRUE) && (pCommissioningCmdPayload->extOptions.gpdKeyPresent == FALSE))

is different from the part where the data is copied:

if( !pCommissioningCmdPayload->extOptions.gpdKeyPresent | pCommissioningCmdPayload->options.securityKeyRequest == TRUE) 

Causing the data to be copied but without the memory region having been allocated previously (as you can see len=1).

The same behavior is present in the sdk 7.10.

Thank you again.

Hi Cristiane,

Thank you for providing an update along with your latest findings.  These results are not expected, as the len should be greater than one.  Can you please provide the contents of pCommissioningCmdPayload both before and after gp_parseCommisioningCmd is called?  I will consider ways to replicate this behavior with my available hardware.  As a side note, setting the Project Properties -> CCS Build -> Arm Compiler -> Optimization level to "off" can help your step debugging become more linear.

Regards,
Ryan

Hi Ryan,

in attached.

Thanks,

Cristiane Bellenzier Piaia

Hi Cristiane,

Everything appears to be correct.  Can you please give me a summary of the behavior you expect and what you are seeing instead?  Is the commissioning reply not being sent or is it malformed?

Regards,
Ryan

Hi Ryan,

the problem is the next malloc (gp_sink.c line 1382) goes out the heap memory because the memory overflow, as you can see in the video.

I'd also would like to reduce the commissioning window. I tried to use the define "PER_TEST_SET_FINDING_BINDING_1_MIN" and also tried to reduce this value ppgCommissioningWindow, but I think the real value is define elsewhere because the time used is set by this function: NLME_GetRemainingPermitJoiningDuration(); 
How can I reduce the commissioning window?

Thanks,

Cristiane Bellenzier Piaia

Thanks Cristiane.  As this behavior lies outside the default TI example operation, I once again encourage you to modify the exposed GP layer as you see fit to resolve the issue.  I will try to replicate the behavior on my end in order to further debug, but cannot make any commitments at this time.

GP commissioning time should depend on ppgCommissioningWindow.  Can you set a breakpoint inside of gp_CommissioningModeInd and view the hasTime/time parameters?  You can then follow this to UI_SetGPPCommissioningMode for the same.

Regards,
Ryan

Hi Ryan,

thank for your suggestion, I will control this and I will be back with my findings.

I have (sorry for that) another doubt.

I can complete the procedure with one sensor, the commissioning and receive the temperature data with success.

But with another sensor, I can not complete the procedure.

My question is: 

Can I do the commissioning procedure and receive the temperature data with more than one sensor at time? 

Thanks again,

Cristiane Bellenzier Piaia

I'm asking a Zigbee Software Developer about this.  Just to be clear, either sensor can be commissioned if they are the first to join?  It's only the second device that tries to commission which fails?  Do you have a sniffer log of the second device attempting to join, and are the responses from the ZC GP stub any different from the first one?

Regards,
Ryan

Hi Ryan,

In this capture I work with 2 sensors: 0x03470049 and 0x03470050. 

With the sensor ending with 49 the commissioning procedure was performed previously and I can receive the temperature data successfully.

With the sensor ending with 50 the commissioning procedure starts with success but not end, as you can see. I can not receive the temperature data.

Remember that when I try to attach the pcapng  file, I received an error message, so the file has an extensive .zip.

Thanks again,

Cristiane Bellenzier Piaia

green_power_50_fail.zip

So it appears that both sensor 49 and 50 are sending temperature data, but the ZC is only observing reports from 49 in its application?  And if you were to restart the test with commissioning sensor 50 instead of 49, would the ZC observe 50's temperature report instead of 49's?

Regards,
Ryan

Yes, both sensors sending temperature data but ZC report just 49.

I try to do this test, but it seems that the 50 never finishes the procedure.

In all my tests, for sensor 50 the procedure ends in the commissioning reply, as you can see in the sniffer capture.

Thanks again,

Cristiane Bellenzier Piaia

Are these two different types of sensors?  I would have expected either sensor to behave the same when used standalone with a factory reset ZC GP sink.  The Commissioning packets appear identical where applicable.  I only see Commissioning Replies for 50 in the sniffer log, not 49, so it is difficult to compare the two.  Nothing seems inherently incorrect about the reply from the ZC GP sink.

For my own tests, I was able to confirm that the default ZC GP sink examples can support multiple GP devices.  Unfortunately, TI's GP device examples do not support security levels or commissioning modes, thus it is difficult to further debug your behavior from my end.

Regards,
Ryan

Good morning Ryan,

No, the same type of sensor. I made some changes in the code and now I can connect with more than one sensor.

Thank you very much for your help.

Cristiane Bellenzier Piaia