Glitches in CC2480 Interface Specification

Hi,

thank you very much for your quick reply! That helped a lot [:)]

Best regards

Jan

Edit: When somebody edit that spec, there is one more thing at Section 5.5.2 Frame Format. The example code given to calculate a FCS is not entirely correct. An unsigned char als "len" value isn't sufficient so handle every framelength possible (maximum is 256 bytes). uint16_t or something similar should do the trick.  Thanks [:)]

I noticed this one today.

ZDO_STATE_CHANGE_IND

State - 1 byte - Specifies the changed ZDO state.

What does ZDO state even mean?

What are the legal values for this byte?

Since there does not appear to be a corresponding SREQ, what causes this message to be generated?

According to the CC2480 Developer's Guide, the nwkAddr of an EndDevice can change automatically.  This happens when an EndDevice rejoins the network.

I have quite a bit of confusion regarding this issue.

1) There are two retry parameters, ZCD_NV_POLL_FAILURE_RETRIES and ZCD_NV_APS_FRAME_RETRIES. 

The documents state a rejoin will occur for the former, but there is no mention of rejoining for the latter.

So what happens when ZCD_NV_APS_FRAME_RETRIES are exhausted?

2) If a rejoin occurs does the device always change its address or does it maintain the same address if it happens to rejoin to the same router?

3) If the nwkAddr changes, is there any way to get notified of this?  Also, are the binding tables updated automatically? 

If I am not using bindings, how would I know the address has changed, and therefore where to send messages?

ZCD_NV_RESPONSE_POLL_RATE

When does the increased poll rate begin and end?

Does it begin polling at the ZCD_NV_RESPONSE_POLL_RATE interval after sending an ZB_SEND_DATA_REQUEST with Ack==TRUE?

Does it continue at this poll rate until a ZB_SEND_DATA_CONFIRM is received?

What happens if the confirm is never received?

ZCD_NV_QUEUED_POLL_RATE

When does this poll rate begin and end?

Does it begin this rate after receiving either a ZB_SEND_DATA_CONFIRM or a ZB_RECEIVE_DATA_INDICATION?

Does it maintain this poll rate indefinitely or is it a single shot timer?  Does it have to be programmed by user code to 0 to turn it off, and then back to some value again to take affect for the next polled data?

If user programmed back to 0, does it take effect immediately, or does a reset/rejoin need to be employed?

Hi all,

I have some questions about the fields of some commands, pls let me know what does those means....

1) In ZDO_END_DEVICE_ANNCE  command, which addr is this NwkAddr? Is this device short address or what??? Also i confused that it'll send a command OTA without using send_data_request command. How does it??

2)In ZDO_END_DEVICE_ANNCE_IND command what are these fields: SrcAddr( Is this shortAddr of device which sent a ZDO_END_DEVICE_ANNCE command? or ....... ) and NwkAddr (I think this is shortAddr of device which gets a callback of  ZDO_END_DEVICE_ANNCE_IND).

3)In GetDeviceInfo: DeviceState means what??

Thanks in advance...

1) NwkAddr and short address are the same thing.  NwkAddr is 2 bytes, IEEEAddr is 8 bytes.

2) I don't have an answer.  It looks like SrcAddr and NwkAddr are the same thing.  I will probably know later this week.

3) From cc2480.h, the device states are

typedef enum
{
  DEV_HOLD,               // Initialized - not started automatically
  DEV_INIT,               // Initialized - not connected to anything
  DEV_NWK_DISC,           // Discovering PAN's to join
  DEV_NWK_JOINING,        // Joining a PAN
  DEV_NWK_REJOIN,         // ReJoining a PAN, only for end devices
  DEV_END_DEVICE_UNAUTH,  // Joined but not yet authenticated by trust center
  DEV_END_DEVICE,         // Started as device after authentication
  DEV_ROUTER,             // Device joined, authenticated and is a router
  DEV_COORD_STARTING,     // Started as Zigbee Coordinator
  DEV_ZB_COORD,           // Started as Zigbee Coordinator
  DEV_NWK_ORPHAN          // Device has lost information about its parent..
} devStates_t;

You can also confirm this by looking at

sapi_cb.c, void zb_GetDeviceInfoConfirm(uint8 param, void *pValue)

Thank u.....

For the 2nd one i tried check, but yesterday i had the h/w problem. So it's not possible from me... Today i'll find and tell u....

Thanks for DeviceState answer........

Talk to u soon.

I have observed that ZDO_END_DEVICE_ANNCE_IND sets SrcAddr and NwkAddr to the same value.

No, both should be different na, bcoz NwkAddr is devices short address which receives the AnnceInd frame and srcAddr is the, 16-bit addr of the msg. I think this is short of the device which broadcosts the EndDeviceAnnce command. If so Short Addr of two devices in a n/w cannot be same na!!!!

Thank u for any sugestion

Ok, nowhere in this thread does it actually state what the ZDO_MGMT_LEAVE_REQ message does.

The API description is for a different message.

So what does this do?

In Documentation also not given anything. What ever they have explained its of no sense at all. Ok just need to wait for new documentaion from TI. Hope ll get it soon by

correcting all mistakes.

P

JeffreyBritton said:

Ok, nowhere in this thread does it actually state what the ZDO_MGMT_LEAVE_REQ message does.

The API description is for a different message.

So what does this do?

Most of the ZDO messages are taken directly from the ZigBee spec, which can be downloaded (even by non-ZigBee Alliance members) from the ZigBee web site.

From the ZigBee spec:

The Mgmt_Leave_req is generated from a Local Device requesting that a Remote Device leave the network or to request that another device leave the network. The Mgmt_Leave_req is generated by a management application which directs the request to a Remote Device where the NLME-LEAVE.request is to be executed using the parameter supplied by Mgmt_Leave_req.

Upon receipt, the remote device shall issue the NLME-LEAVE.request primitive using the parameters supplied with the Mgmt_Leave_req command. The results of the leave attempt shall be reported back to the local device via the Mgmt_Leave_rsp command.

In plain-speak, this message is sent by a "management application", and is asking that either the recipient device or one of its children leave the network.  This message can also request the removal of the target's children, and indicate whether or not the removed node(s) should seek to rejoin the network.

Thanks for the response.

However the download for the Zigbee Alliance specification has a Legal Notice with the following clause:

"No part of this specification may be used in development of a product for sale without becoming a member of ZigBee Alliance."

In general, the ZigBee Alliance requires you to be a member of the Alliance if you're using ZigBee in commercial products (i.e. "product for sale").  I don't believe that the restriction on downloading / using the ZigBee spec is any more restrictive than that membership requirement for using the ZigBee IP -- that is, if you meet the requirements to use ZigBee without joining the ZigBee Alliance, you should also be free to download the spec without joining the Alliance (standard caveat: IANAL).

Here're some ZigBee Alliance web pages about membership requirements for different classes of users:

• ZigBee Alliance Membership FAQ
• ZigBee Alliance Membership Requirements

I am still a little unclear on the need to join the Zigbee alliance.

We plan to sell a commercial product using the TI CC2480 chip.

The membership requirements state, "Companies using ZigBee certified products designed by others" are not required to join the Zigbee alliance.

However, the FAQ states: "If my company uses a ZigBee module in my product, do I need to be a member?, Yes".

I don't know if the CC2480 falls under the category ZigBee module.

I was assuming that by using a TI product that it would shield our company from needing to join the Zigbee Alliance.

Let me clarify... when they say "Companies using Zigbee certified products designed by others", they are referring to system integrators. Not OEMs, which is
the category you fall under. CC2480 falls under the category of Zigbee module.

The SYS_RESET_REQ (§ 6.1.1) frame seems incorrect in the data sheet because it is not effectively used, another frame is used to achive a watchdog reset.

A frame that cause a watchdog reset is : lenght = 0x02, Cmd0 = 0x46, Cmd1 = 0x09, data 0 = 0, data 1 = 0.

Maybe it would work with lenght = 0x01, but the function used to build the frame always sets the lenght to 2 + extra data len (function sapiReq, in sapi.c).

Maybe the SYS_RESET_REQ frame in the spec works also, but it is not the one used in the evaluation kit.

So far I haven't noticed differences between a hardware reset, and this reset.

However the spec recomends (§7.1) to use the reset line before other ways.

This may also appear as a glitch since the example code avoids to do that...

PierreAD

I think I found another one:

The Interface specification of the CC2480 says at AF_DATA_REQUEST:
Length can be 0x0A-0x5E
while the Data can be 0-128 bytes long

This seems a bit confusing, since 0x5E < 128