New SW reference design for designs using ZNP - A portable SW framework for host microcontrollers

Hi TheDarkSide,

It is very useful framweork, I'm already trying it, thanks for your work.

However, so far I have stranges in ZDO_NWK_ADDR_RSP. I've compiled cmdLine example, all seems fine until I tried get response on ZDO_NWK_ADDR_REQ. I use CC2531 USB dongle as ZNP (compiled from Z-Stack Home 1.2.1). Also I has external ED with MAC: 0x00124B0004DFF718


Here is listing #1 how cmdLine work:

ZDO_NWK_ADDR_REQ

Command: ZDO_NWK_ADDR_REQ
Enter IEEEAddress: (8B)
00124b0004dff718
Enter ReqType: (1B)
0
Enter StartIndex: (1B)
0
rpcSendFrame: Blocking on RPC sem
rpcSendFrame: Sending RPC
rpcTransportWrite : len = 15
writing 8 bytes (offset = 0, remain = 15)
writing 7 bytes (offset = 8, remain = 7)
SOC OUT --> 15 Bytes: SOF:FE, Len:0A, CMD0:25, CMD1:00, Payload:18:F7:DF:04:00:4B:12:00:00:00, FCS:42
rpcSendFrame: waiting for SRSP [05]
rpcTransportRead: read 1 bytes
rpcTransportRead: read 1 bytes
rpcTransportRead: read 4 bytes
SOC IN  <-- 6 Bytes: SOF:FE, Len:01, CMD0:65, CMD1:00, Payload:00, FCS:64
rpcProcess: processing expected srsp [05]
rpcProcess: writing 4 bytes SRSP to head of the queue
rpcSendFrame: Receive SRSP
rpcWaitMqClientMsg: timeout=50
rpcWaitMqClientMsg: waiting on queue 50:1427452123:50000000
rpcWaitMqClientMsg: processing MT[4]
zdoProcess: processing CMD0:65, CMD1:0
processSrsp: unsupported message
rpcWaitMqClientMsg: timeout=1000
rpcWaitMqClientMsg: waiting on queue 1000:1427452124:0
rpcTransportRead: read 1 bytes
rpcTransportRead: read 1 bytes
rpcTransportRead: read 24 bytes
SOC IN  <-- 26 Bytes: SOF:FE, Len:15, CMD0:45, CMD1:FF, Payload:00:00:00:00:80:00:00:00:00:00:18:F7:DF:04:00:4B:12:00:0E:1B:00, FCS:57
rpcProcess: writing 24 bytes AREQ to tail of the que
rpcWaitMqClientMsg: processing MT[24]
zdoProcess: processing CMD0:45, CMD1:ff
zdoProcess: MT_ZDO_MSG_CB_INCOMING
mtZdoMsgCbIncomingCb
SrcAddr: 0x0000
WasBroadcast: 0x00
ClusterID: 0x8000
SecurityUse: 0x00
SeqNum: 0x00
MacDstAddr: 0x0000

rpcWaitMqClientMsg: timeout=1000
rpcWaitMqClientMsg: waiting on queue 1000:1427452124:0
rpcWaitMqClientMsg: Timed out [-1] - Connection timed out

Enter CMD

first of all strange looks hihghlighted with red above CMD1:FF and MAC is 0, in incoming packet I see correct MAC see green above, seems somwhere is incorrect parsing?

Hi Vasiliy,

This is actually the right behavior but it is missing the parsing of the last section of the message. The reason why you are seeing the CMD1: FF is because the coordinator is the parent of the ED and the coordinator is the one responding in behalf of its child. If you see the ClusterID is 0x8000 which is the clusterID of the NWK_ADDRS_RSP. Also, you are seeing MacDstAddr = 0x0000 because the Coordinator is the one dealing with this request and this field is referring to the short address not the IEEE address.

If you send the ZDO_NWK_ADDR_REQ to a router you should see a different behavior.

I will make the necessary changes to the code to parse correctly the mtZdoMsgCbIncoming message and push the changes to the repository.

Thanks for reporting this issue,
Hector

The design guide is for the TIVA C launchpad, would the following also be compatible with the original Launchpad (MSP-EXP430G2)?

Oswaldo,

    The current examples will not run on MSP-EXP430G2, If it where possible to run TIRTOS on this launchpad then porting the example from the TIVA C Launchpad should be relatively easy. However as far as I can see the MSP430G2 family is not supported by TI RTOS, you could raise the question on the TI-RTOS forum (e2e.ti.com/.../tirtos) for confirmation.

Currently we do not have any examples that run on MSPWare (i.e. with No OS), but we would like to hear if this is something people would be interested in.

Regards, TC.

I am currently using CC2530EM (F256) devices, there seems to only be CC2538 .HEX files to flash program the device in the ...\znp-host-framework-znp-host-framework\bin folder.

Is there a a similar already built .HEX file for the CC2530? If not, what is a possible solution to solve this issue?

Thanks!

Hi Oswaldo,

Yes there is, you can use the images provided in the Z-Stack installation in the following directory:

C:\<Z-Stack Instalation folder>\Projects\zstack\ZAP\ZNP-HexFiles\CC2530ZNP-Pro-Secure_LinkKeyJoin.hex

You can also build your own ZNP image using the ZNP project in Z-Stack.

Hector

Hi Oswaldo,

Does this happen with the other projects as well or only in dataSendRcv  project?

Can you open dbgPrint.h and set PRINT_LEVEL to be PRINT_LEVEL_VERBOSE.

After this, build the project again and share the log here so I can see what is exactly happening.

Regards,
Hector

Oswaldo,

The reason why this is happening is because the default CC2530 ZNP code is not using UART, you will have to modify the code on the CC2530 to use UART.

You can do this by opening the CC2530 ZNP project on IAR, then open OnBoard.c file and modify the following code in the function

void InitBoard( uint8 level )

.

#else
    //znpCfg1 = P2_0; //remove this line
    //znpCfg0 = P1_2; //remove this line
    // Tri-state the 2 CFG inputs after being read (see hal_board_cfg_xxx.h for CFG0.)
    //P1INP |= BV(2); //remove this line
    //P2INP |= BV(0); //remove this line
    
    znpCfg1 = ZNP_CFG1_UART; //add this line
    znpCfg0 = ZNP_CFG0_32K_XTAL; //add this line
    
#endif

Let me know if you have any questions,
Hector

Hi Hector,

Sorry for late response, had to get new IAR License. I have made the changes to the OnBoard.c file and when I run dataSendRcv I am still getting the same issue with "Network Issue" error after being asked to start/join network. Were you able to get the same project working with a CC2530 device? Thanks!

Oswaldo

rpcWaitMqClientMsg: timeout=10
rpcWaitMqClientMsg: waiting on queue 10:0:10000000
rpcWaitMqClientMsg: Timed out [-1] - No error
flushed 0 message from msg queue
rpcWaitMqClientMsg: timeout=50
rpcWaitMqClientMsg: waiting on queue 50:0:50000000
rpcWaitMqClientMsg: Timed out [-1] - No error
rpcSendFrame: Blocking on RPC sem
rpcSendFrame: Sending RPC
SOC OUT --> 10 Bytes: SOF: X, Len: X, CMD0: X, CMD1: X, Payload: X Éý X(null) X(null) X Éý X Éý FCS: X
rpcSendFrame: waiting for SRSP [01]
rpcSendFrame: SRSP Error - CMD0: 0x X CMD1: 0x X

NV Write Startup Option cmd sent[1]...
network start failed
rpcSendFrame: Blocking on RPC sem
rpcSendFrame: Sending RPC
SOC OUT --> 5 Bytes: SOF: X, Len: X, CMD0: X, CMD1: X, Payload: FCS: X
rpcSendFrame: waiting for SRSP [01]
rpcSendFrame: SRSP Error - CMD0: 0x X CMD1: 0x X
rpcSendFrame: Blocking on RPC sem
rpcSendFrame: Sending RPC

Oswaldo,

I have tested this, and it works for me.

Have you done the required modifications to the EM adapter boosterpack?

If you haven't done them, please see the section Modifying the BoosterPack in the design guide .

Also do the modifications based on the pictures (Figure 6 and Figure 7) and not the text since I believe steps "4" and "6" have a typo.

Regards,

Hector

Several Questions:

1. What is the difference in terms of the usages and capabilities between this framework and Ti Z Stack. I am trying to figure what I should use.
2. Based on the instructions and documents, "ZNP Host Framework" works with POSIX-compatible OS, which is most Linux distributions. I am trying to figure how to test this settings with a CC2538 Eval Module and a Linux system. On the document, it only says "connecting CC2538 Eval module to a Linux system", but it does not say how to connect from HW interface point of view. Is there any instruction or document about how to set up the connection in this scenario (not in the LauchPad scenario)?
3. Does this framework only support using CC2592 with CC2538?

Thanks,
Chih-fan

Hi,

Is there any user guide for porting the framework on Windows?

or 

Can you please share any example for using the framework on windows.

Regards

Srikanth

As I know, there is no related example using framework on windows system. I think you have to refer to Linux reference design and revise accordingly.

Hi Ting,

The ZNP host framework contains only low level ZNP APIs, while the Z-Stack Linux gateway has a full implementation of the ZigBee Cluster Library and also provides a server to access the gateway through an internet connection.

If your concern is about the  CC2530/CC2538 ZNP firmware that comes with the Linux Gateway vs the ZNP firmware in the host framework then there is no big difference but if you are using the Linux gateway then you should use the ZNP firmware provided with the linux gateway, there is no benefit on trying to use the ZNP firmware provided in the ZNP Host Framework with the Linux Gateway.