CC2630: ZNP-Host-Framework SensorTag, No ANNCE Break or msg

Hello Gerjon,

I would first suggest you gather a good understanding of ZNP MT interface communication, perhaps using Z-Tool.  YK's blog has some good tutorials for this:

https://sunmaysky.blogspot.com/2015/10/setup-zigbee-ha-coordinator-with-ti.html 
https://sunmaysky.blogspot.com/2016/01/how-to-use-sensortag-cc2650stk-with-cc.html 

I would also make sure that the network is formed, open for joining, and discovering devices as described in Section 6.5 of TIDU757.  It would also bee good to set up a sniffer to understand what over-the-air transactions are occurring.

Regards,
Ryan

Dear Ryan,

i think i have a different version of the ZNP-Host-Framework. In the refferanced document says i can put in ZDO messages in the example. as shown in the image that does not work for mine. is this a version thing or am i running a different example?
If it is a different version is this compatible with freertos?

Regards,
Gerjon

Gerjon,

The images did not upload correctly, you may want to try again.  The only version I am aware of is provided on the TIDC-ZNP-HOST-SW3 tool page or https://git.ti.com/cgit/znp-host-framework/znp-host-framework and solely uses TI-RTOS, however I am aware that it uses the CC2538 ZNP.  From where do you get the CC2630 ZNP image?

Regards,
Ryan

Dear ryan,

Lets try again with the image.
The ZNP on the cc2630 is the original delivered with z-stack 1.2.2a. edited to work with the cc2592 and a custom pinout.
I will take a look for the source of the tm4c1294ncpdt image.

Regards,
Gerjon

It appears that the network is open and that the ZED is attempting to join, the ZNP even receives a Device Annce message, but that the ZED leaves shortly afterwards.  Can you provide the sniffer log source?

Regards,
Ryan

Dear Ryan,

I did not have the logs from that screenshot so i made a fresh one. the tag was already running when i stared the program. after 30 seconds i turned it off, waited a few and turned back on. I waited for a while and then i did the commands on that are on putty. then i saved it all and made the screenshot.

Not that the following commands are not in the original file:
'p' - ping
'b' - make new bind

these commands are added and preform the next:
'b' =  case 'b':
              consolePrint("binding device\n");
              break;

'p' = case 'p':
            consolePrint("Ping Send\n");
            status = sysPing();
            if(status == 0){
                consolePrint("Ping success\n");
            }
            else{
                consolePrint("Ping failed\n");
                consolePrint(status);
                consolePrint("\n");
            }
            break;

Regards,
Gerjon

0x0B(4205MHZ)_20_4_23_8_44.psdCOM18_20_4_24_8_44.rtf

First time, your node (IEEEAddr: 0x00124B0007986785) joins network with short address 0xD711 but it doesn't receive network key from coordinator so it leaves because of unauthenticated. Later, the same node (IEEEAddr: 0x00124B0007986785) joins again with short address 0xF0E7 and it receives network key this time and it works fine. According to your logs, the device joins coordinator successfully.

Dear YiKai Chen,

Good to have the conformation that joining works. The spesific problem i have i do not get any way of conformation from the firmware on the tm4c1294ncpdt even when i add break points to anywhere something like ANNCE is mentiond. it does not trigger the break. i need to have the Break to find out how to get the short address to make a bind and read the temperature.
Or am i taking the wrong approach and is there a spesific function, that manages the storage and returns the joined device's?

Regards,
Gerjon

Using cmdLine example, you can receive device announcement in mtZdoEndDeviceAnnceIndCb

As YK mentioned, if you are operating the TIDC-ZNP-HOST-SW3 serviceDisc example (described in Section 2 and 6.5.5 of the UG) and not receiving a "New device joined network" message inside the terminal then you will need to debug the ZNP to determine if the MT_ZdoEndDevAnnceCB is triggering to send the Device Annce message to the host (requires MT_ZDO_CB_FUNC to be defined, this appears functional as shown through the Z-Tool logs).  If this occurs as expected then you will need to further debug the TM4C1294NCPDT to determine why it is not received/recognized as expected.

Regards,
Ryan

Dear,

Thank you, i have the serviceDisc running. no it is true I do not get the screen as represented in in Section 2 and 6.5.5 of the UG.
Yes it appears that mtZdoEndDeviceAnnceIndCb is not triggered properly.

All i have is that mtZdoEndDeviceAnnceIndCb gets called in: static mtZdoCb_t mtZdoCb. this gets used in the call: zdoRegisterCallbacks(mtZdoCb); within the function uint32_t appInit(void). This is used in the main for task appTaskFXn.

static uint8_t mtZdoEndDeviceAnnceIndCb(EndDeviceAnnceIndFormat_t *msg) > static mtZdoCb_t mtZdoCb > zdoRegisterCallbacks(mtZdoCb); > uint32_t appInit(void) > static void appTaskFxn(void *pvParameters).

All these functions are in the servDisc.c exept for appTaskFxn. This is a 1:1 copy of the git so this all appears good to me. Am I missing a call or am I missing an example document?

Regards,

Gerjon

Hello Gerjon,

Based on Z-Tool's ZDO_END_DEVICE_ANNCE_IND message I believe that the ZNP is correctly passing along the Device Annce message to the host through UART, however I do not know what issue could be present on the znp-host-framework code as it is archived and I've never worked with it before, nor do I have access to a TM4C1294NCPDT device to test with.  Are you able to monitor other callbacks?  Does the device not appear when checking the device list?

Regards,
Ryan

Dear Ryan

No the device does not show up on the list, as shown in the image.

I added raw communication. com18 is what gets transmitted form the cc2630 and com19 is what gets transmitted from the TM4C1294NCPDT

Regards,

Gerjon

0x0B(4205MHZ)_20_4_29_8_53.psd

Dear Ryan,

I Have found some extra info.
it appear that the join message is wrong, becouse the rpcProcess in rpc.c triggers the rpcProcess: fcs error.

fcs = calcFcs(&rpcBuff[0], (len + 3));
            if (rpcBuff[len + 3] != fcs)
            {
                dbg_print(PRINT_LEVEL_WARNING, "rpcProcess: fcs error %x:%x\n", rpcBuff[len + 3], fcs);
                consolePrint("rpcProcess: fcs error %x:%x\n", rpcBuff[len + 3], fcs);
                return -1;
            }

Regards,

Gerjon

The transmitted TM4C1294NCPDT values indicate one SYS_OSAL_NV_WRITE, one SYS_RESET_REQ, four more SYS_OSAL_NV_WRITE, one ZDO_STARTUP_FROM_APP, then one AF_REGISTER.  You can interpret these packets yourself using the Z-Stack Monitor and Test API.  This all appears to be startup operation and there is no indication of joining devices.  The transmitted CC2630 ZNP indicates successful responses to the SYS_OSAL_NV_WRITEs, a network startup and change of ZDO state, a successful AF_REGISTER, followed by the ZDO_END_DEVICE_ANNCE_IND, and the last being a ZDO_TC_DEVICE_IND.  All of the SOFs are correct but I cannot comment on the FCS error.  Once again it doesn't appear out of the ordinary on the packet log or show as incorrect in Z-Tool.  The CC2630 was not tested with znp-host-framework, I don't know if the same would occur were you to use a CC2538.

Regards,
Ryan

Glad to hear it Gerjon, thank you for updating with the solution.

Regards,
Ryan