CC2652P: Unable to pair devices

Try to refer to https://sunmaysky.blogspot.com/2017/02/use-ztool-z-stack-30-znp-to-set-up.html to do the test. I suggest you also enable sniffer to check what happens exactly over the are. If you still cannot make it, please provide your sniffer log.

Hi YK,

As per the link i tried, executing the first command, it returns the following error message,

<TX>11:31:08.47 COM5 SYS_OSAL_NV_WRITE (0x2109)
Id: 0x0003
Offset: 0x00
Len: 0x01
Value: . (0x01)

<RX>11:31:08.47 COM5 SYS_OSAL_NV_WRITE_SRSP (0x6109)
Status: NV_OPER_ERROR (0xA)

How to check whether the ZNP firmware is right?

Just test this with ZNP inside simplelink_cc13x2_26x2_sdk_5_10_00_48 and I can do it successfully. Do you use LAUNCHXL-CC26x2R1 to test this?

Yes I am using LAUNCHXL-CC26x2R1, and compiled the ZNP from the examples. But it is giving error for me.

I tried the same with Koenk's firmware it is working, but why it is not happening with the compiled ZNP examples?

For your reference, I test with ZNP example which is compiled by myself on CCS 10.3 and it works.

Karthick,

Please erase all memory before reprogramming.  This can be done with Uniflash, Flash Programmer, or the CCS Debug Configurations. There could be NV memory flash sections retained from previous builds which are causing an issue with ZNP NV MT API.

Regards,
Ryan

Hi YK, I tried using the link you provided, but there are 2 commands where the response data differs from the link, and I could successfully pair end devices but when I try to control the paired device from AF_DATA_REQUEST command it shows invalid parameter error.

Can you show me how you use AF_DATA_REQUEST command in ZTool?

Here it is

<TX>02:43:10.96 COM5 AF_DATA_REQUEST (0x2401)
DstAddr: 0x3625
DestEndpoint: 0x01
SrcEndpoint: 0x07
ClusterID: 0x0006
TransID: 0x01
Options: 0x02
Radius: 0x07
Len: 0x03
Data: ... (0x01, 0x01, 0x01)

<RX>02:43:10.96 COM5 AF_DATA_REQUEST_SRSP (0x6401)
Status: afStatus_INVALID_PARAMETER (0x2)

I remember there is something wrong with AF_DATA_REQUEST in ZTool. Try to use AF_DATA_REQUEST_EXT instead of AF_DATA_REQUEST

Hi I tried the same AF_DATA_REQUEST with same Z-tool but with CC2531 USB stick the same works well, pls find below

<TX>03:33:35.2 COM7 AF_DATA_REQUEST (0x2401)
DstAddr: 0x0F32
DestEndpoint: 0x01
SrcEndpoint: 0x07
ClusterID: 0x0006
TransID: 0x01
Options: 0x02
Radius: 0x07
Len: 0x03
Data: ... (0x01, 0x01, 0x00)

<RX>03:33:35.21 COM7 AF_DATA_REQUEST_SRSP (0x6401)
Status: afStatus_SUCCESS (0x0)

<RX>03:33:35.21 COM7 AF_DATA_CONFIRM (0x4480)
Status: afStatus_SUCCESS (0x0)
Endpoint: 0x07
TransID: 0x01

<RX>03:33:35.28 COM7 AF_INCOMING_MSG (0x4481)
GroupID: 0x0000
ClusterID: 0x0006
SrcAddr: 0x0F32
SrcEndpoint: 0x01
DstEndpoint: 0x07
WasBroadcast: 0x00
LinkQuality: 0x61
SecurityUse: 0x00
Timestamp: 0x00056AAE
TransSeqNumber: 0x00
Len: 0x05
Data: ..... (0x08, 0x01, 0x0B, 0x00, 0x00)

An additional information regarding this problem, when I assign values to the coordinator through AF_REGISTER I could able to control the lighting load, however I am not getting the feedback in AF_INCOMING_MSG. Is there anything I could check ?

Does your device send any AF message to you? I would suggest you to use sniffer to check this.

I tried binding the device, the binding is successful but there is not AF_INCOMING_MSG when the button is pressed

Do you setup sniffer to check what exactly happens over the air?

test data.psdhere is the sniffer file

There is no AF message communicated between devices in your sniffer log. Are you sure you sniff correct channel?

Hi Karthick,

Unlike the CC2531 ZNP firmware, the CC2652 ZNP does not have MT_AF_CB_FUNC defined by default in Stack/Config/znp_cnf.opts which could be causing the behavior you've described.  Please rebuild the project accordingly and test again.  You can debug AF_DataRequest on the CC2652 to determine why afStatus_INVALID_PARAMETER is returned.

Regards,
Ryan

The same problem happen for me even when using Koenk's firmware, Do you have any Ztool script which we used to run similar like CC2531 ?

Have you use sniffer to confirm there is AF message sent to your ZNP coordinator?

I don't know whether Koenk's solution has MT_AF_CB_FUNC defined, and a Z-Tool 3.0 script should work for any TI Zigbee 3.0 device so long as you change the communication interface (i.e. UART COM Port).  Further debugging could be valuable and I also agree with YK that a detailed sniffer log would be helpful.

Regards,
Ryan

But when I execute the Z-Tool script which is working well for CC2530/1 to CC2652, it keep on resetting, how to stop that continuous resetting.

Please provide more information about your Z-Tool script and debug information from your CC2652R.  I'd recommend against using sysReset/ZB_SYSTEM_RESET (deprecated Simple API) in your test, SYS_RESET is preferable (see the Monitor and Test API).

Regards,
Ryan

Let me explain the case from the beginning, earlier I used the CC2530  ZNP and used a script file to initiate the coordinator, the CC2530 is not sufficient for my larger network so I planned to upgrade the ZNP and used the CC2652 launchpad, I just compiled the ZNP firmware from the examples provided in the SDK, I could successfully able to connect the coordinator in the Z-tool, and I followed the methods mentioned in the link https://sunmaysky.blogspot.com/2017/02/use-ztool-z-stack-30-znp-to-set-up.html to setup the coordinator and I could able to connect the end device successfully, Then I used the AF_DATA_REQUEST to control the end device after configuring the AF-REGISTER, the device get controlled but there is no feedback in the AF_INCOMING_MSG format, I also tried BINDING the end device with the coordinator but no use. I need help in implementing a powerful coordinator using CC2652, kindly help. I downloaded the script file from the link https://sunmaysky.blogspot.com/search/label/Z-Stack.

Without sniffer log, it's difficult to judge what happens in your test. Please provide your sniffer log.

I'm still not sure whether MT_AF_FUNC/MT_AF_CB_FUNC have been defined in the MT project and this is essential for receiving AF_INCOMING_MSG.  At this point, the situation is clear but we need more debug information to continue investigating.

Regards,
Ryan

Thank you YK and RYAN, I will collect more information and get back to you regarding this. By the way where can i check the MT_AF_FUNC/MT_AF_CB_FUNC in the project? pls check the image of the znp_cnf.opts file attached

You mean the MT_AF_FUNC/MT_AF_CB_FUNC should be declared in the pre defined symbols under Arm Compiler?

Regards

Karthick.D

According to your znp_cnf.opts, MT_AF_FUNC/MT_AF_CB_FUNC had been defined.

Your znp_cnf.opts has the correct configuration, please make sure to clean the ZNP project and rebuild, then erase all memory before re-programming the SimpleLink device.

Regards,
Ryan

Hi Ryan,

I am trying to capture sniffer log using CC2531, but after the end device pairing with the CC2652 coordinator there is no trace captured in the screen, Is the CC2531 not suitable to capture CC2652 ?

There is no problem to use CC2531 to capture Zigbee packets sent by CC2652. You should make sure you sniff correct channel.

hi here is the sniffer trace CC2652_data.psd

According to sniffer log, it seems that your coordinator using 7 as endpoint but the device send ZCL ON/OFF report to endpoint 0x0B. You can try to set 0x0B as endpoint on your coordinator to see if it works.

Hi YK, 

I tried changing the end point to 0x0B,

<TX>11:50:29.93 COM5 AF_REGISTER (0x2400)
EndPoint: 0x0B
AppProfID: 0x0068
AppDeviceId: 0x0064
AppDevVer: 0x00
LatencyReq: NO_LATENCY_REQS (0x0)
AppNumInClusters: 0x04
AppInClusterList: 0x0000, 0x0006, 0x0008, 0x0012
AppNumOutClusters: 0x04
AppOutClusterList: 0x0000, 0x0006, 0x0008, 0x0012

<RX>11:50:29.93 COM5 AF_REGISTER_SRSP (0x6400)
Status: afStatus_SUCCESS (0x0)

Even after changing it to 0x0B there is no reply in AF_INCOMING_MSG pls check below response

<TX>11:51:34.39 COM5 AF_DATA_REQUEST (0x2401)
DstAddr: 0x9566
DestEndpoint: 0x01
SrcEndpoint: 0x0B
ClusterID: 0x0006
TransID: 0x01
Options: 0x02
Radius: 0x07
Len: 0x03
Data: ... (0x01, 0x01, 0x01)

<RX>11:51:34.39 COM5 AF_DATA_REQUEST_SRSP (0x6401)
Status: afStatus_SUCCESS (0x0)

<RX>11:51:34.41 COM5 AF_DATA_CONFIRM (0x4480)
Status: afStatus_SUCCESS (0x0)
Endpoint: 0x0B
TransID: 0x01

<RX>11:51:34.44 COM5 ZDO_SRC_RTG_IND (0x45C4)
DstAddr: 0x9566
Relay Count: 0x00
Relay List

<RX>11:51:34.44 COM5 ZDO_SRC_RTG_IND (0x45C4)
DstAddr: 0x9566
Relay Count: 0x00
Relay List

After you change endpoint, do you use sniffer to check if there is any command sent to endpoint 0x0B?

complete.psd Hi YK, after changing the endpoint here is the sniffer, there is no change after the endpoint change

From my observation there is no problem with the firmware side I think, because I flashed ZNP firmware from Ti's ZigBee gateway under Firmware\ZNP, after flashing this prebuilt firmware also the behavior is similar that is no AF_INCOMING_MSG. The problem should be somewhere else.

You can check the following screenshot of your sniffer log and you can see your coordinator use profile ID: 0xFFFF. That is why Ryan asked you to fix it.

But I am configuring it everytime I connect Ztool, I use AF_DATA_REGISTER to assign 104 as profile ID.

Dear YK and Ryan, yes you are right, there is format issue, now it is working, thank you for your support.

It’s good to know it works now. If you don’t have further question, please mark this thread as answered.