• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 55 subscribers
  • Views 359 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

CC2652P7: zc_thermostat_sink ignores GP channel request

Shuyang Zhong
Expert 4265 points
Part Number: CC2652P7
Other Parts Discussed in Thread: CC1352P7

A customer is trying to commission a GPD to zc_thermostat_sink running on CC1352P7, but found that the GPS did not response to the channel request from GPD.

After single stepping into the code, the customer found that the channel request was received inside MAC_CbackEvent() and gpSecRecMsgSend(), but zclGp_GpCommissioningNotificationCommandCB() was not triggered:

The SDK is simplelink_cc13xx_cc26xx_sdk_7_10_01_24. Would you please help look into this issue?

Best regards,

Shuyang

  • 0
    TI__Guru**** 208047 points

    Hi Shuyang,

    Can you please have the customer confirm that they are able to join a gpd_temperaturesensor example to the zc_thermostat_sink and communicate GP packets accordingly?  Further instructions are available in the project READMEs as well as the Green Power Application Overview section of the Z-Stack User's Guide.  Then they should use a sniffer log to compare the transaction between the TI GPD and their own.  Please provide further logs and the specific GPD product if they continue to experience issues.

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    TI__Expert 4265 points

    Hi Ryan,

    The customer has tried gpd_temperaturesensor example and it is able to join zc_thermostat_sink, but gpd_temperaturesensor starts commissioning by sending a commissioning request, yet their own GPD starts by a channel request. The problem is zc_thermostat_sink does not process the channel request.

    The GPD device is based on Atmel SMAR21 running Zigbee 3.0 stack. Please find 2 sniffer logs showing a successful commissioning(GP_OK.pcapng) between the customer's GPD and GPS device as well as a failed one(GPD_and_GPS.pcapng) between the same GPD and CC1352P7. In GPD_and_GPS.pcapng the GPD sent the channel request at line #2978, this message was received in our MAC layer but not the APP layer.

    GP_OK.pcapng

    GPD_and_GPS.pcapng

    Best regards,

    Shuyang

  • 0 in reply to Shuyang Zhong
    TI__Guru**** 208047 points

    Thank you for the additional information.  If these channel requests truly are received in gpSecRecMsgSend then they are classified as mzstackmsg_CmdIDs_GP_SECURITY_REQ events and are further processed by gp_processSecRecMsg and GP_SecReq (gp_common.c).  As the device is a GP sink, it should then enter gp_SecurityOperationSink (gp_sink.c).  Can you please further debug this function to establish how the GP_CHANNEL_REQ_COMMAND_ID is processed and how this differs from the successful commissioning request case?  Ultimately the customer should modify the application accordingly to accommodate their unique device.

    Regards,
    Ryan