Zigbee Coordinator Address Isn't 0

[wareagle]

    Hello,
I'm aware that in a Zigbee network, the coordinator should always have a NWK address of 0x0000.  However, when i try to send messages from a router to the coordinator using the address 0x0000, this does not work.  Also, I had the NCB diplay the value of gNwkData.aShortAddress on the LCD, and it prints 9A6.  Sending a message from the SRB to the NCB using the address 0x09A6 DOES work.  So, why is the address 0x09A6 and not 0x0000?

Thanks,
Kurt

P.S. Please do not just tell me to go read the Zigbee specification, I've tried that.

[Mads]

wareagle,

first of all, using a protocol analyzer would be a great help in this case so you can see what is happening "over the air". Any serious development would need a tool like that.

But I would asume you are not filling out the address information correctly.

here is an example function doing what you are trying:

oid SendIpodRemoteCommandOTA(IpodRemoteCommand_t cmd) {
  afAddrInfo_t  addrInfo;
  uint8_t       TransmitBuffer[1];

  TransmitBuffer[0] = cmd; 

  /* set up address information */
 addrInfo.dstAddrMode = gZbAddrMode16Bit_c; /*Always send packet to coordinator*/
 addrInfo.dstAddr.aNwkAddr[1] = 0x00;
  addrInfo.dstAddr.aNwkAddr[0] = 0x00;
  addrInfo.dstEndPoint = appEndPoint;
  addrInfo.srcEndPoint = appEndPoint;
  addrInfo.txOptions = gApsTxOptionNone_c;
  addrInfo.radiusCounter = afDefaultRadius_c;

  /* set up cluster */
  addrInfo.aClusterId[0] = endPointList[0].pEndpointDesc->pSimpleDesc->pAppInClusterList[0];
  addrInfo.aClusterId[1] = endPointList[0].pEndpointDesc->pSimpleDesc->pAppInClusterList[1];
 
  /* send the data request */
  (void)AF_DataRequest(&addrInfo, sizeof(TransmitBuffer), TransmitBuffer, NULL);

/Mads

Message Edited by Mads on 2008-04-09 11:16 PM

[wareagle]

A protocol analyzer would be nice, but I am just a student working on a senior design project.

From what I can tell, your code looks similar to mine:

 /* set up address information */
  addrInfo.dstAddrMode = gZbAddrMode16Bit_c;
  Copy2Bytes(addrInfo.dstAddr.aNwkAddr, 0x0000);
  addrInfo.dstEndPoint = 1;
  addrInfo.srcEndPoint = appEndPoint;
  addrInfo.txOptions = gApsTxOptionNone_c;                   
  addrInfo.radiusCounter = afDefaultRadius_c;
 
  /* set up cluster */
  Copy2Bytes(addrInfo.aClusterId, appDataCluster);
 
  /* send the data request */
  (void)AF_DataRequest(&addrInfo, sizeof(TxOTADataBuffer), TxOTADataBuffer, NULL);


As I said earlier, this does not work. However, if i replace 0x000 with 0x9A6, it does work. So it appears that for some reason the coordinator has NWK address of 0x9A6.  How would this happen?  This is a project that was created in Beekit (Beestack Codebase) based on the GenericApp.

Thanks

[DedsBee]

Hi wareagle,

I had a similar problem and the solution was to configure the destination address NOT using the function Copy2Bytes. I really don't know why this function not works sometimes, but I usually avoid using it. Try to write the destination address like this:

addrInfo.dstAddr.aNwkAddr[0] = 0x00;
addrInfo.dstAddr.aNwkAddr[1] = 0x00;

It should work.

Regards,

DedsBee

[wareagle]

DedsBee,

You were right!  I have no idea how copy2bytes() is messing things up, but it is.  Assigning the address like you said does work.  Thank you very much for your help.

Kurt

[DedsBee]

Wareagle,

Good to know it's working now! Maybe someone from Freescale could tell us why Copy2Bytes doesn't work sometimes.

Regards,

DedsBee

[allawtterb]

It looks like maybe Copy2Bytes is expecting a pointer to be passed to it.  When you pass 0x0000 it is trying to copy the bytes located at address 0x0000.  The compiler should throw a fit for a type mismatch but try:

Code:

unsigned int *paddress;*paddress = 0x0000;Copy2Bytes(addrInfo.dstAddr.aNwkAddr, paddress);

 

My best guess is that something along these lines is going on.

[Mads]

allawtterb is correct. It is because the Copy2bytes() is not used correctly.

Note this macro is available for you to inspect in the code, just right click on it and "go to definition":

From Embeddedtypes.h

#define Copy2Bytes(aVal1, aVal2) (*((uint16_t *)(aVal1)) = *((uint16_t *)(aVal2)))

Br,

Mads

[allawtterb]

---

Mads wrote:

From Embeddedtypes.h

#define Copy2Bytes(aVal1, aVal2) (*((uint16_t *)(aVal1)) = *((uint16_t *)(aVal2)))

Br,

Mads

---

That would explain why the compiler wasn't complaining.  Type casting them to pointers then dereferencing them. 

[wareagle]

That makes sense, thanks to all for the explanation.  Out of curiousity, can anyone explain why I was able to send a message to the NCB using the address 0x09A6 (using Copy2Bytes)?  Does the NCB have TWO NWK addresses?

[allawtterb]

---

wareagle wrote:

That makes sense, thanks to all for the explanation.  Out of curiousity, can anyone explain why I was able to send a message to the NCB using the address 0x09A6 (using Copy2Bytes)?  Does the NCB have TWO NWK addresses?

---

Because at the address 0x09A6 and 0x09A7 was 0x00 and 0x00.  It was still sending an address of 0. 

[wareagle]

Yes, that is what I thought originally.  However, I remembered the test I did where I had the NCB print its NWK address (more specifically, the value of gNwkData.aShortAddr) on the LCD (using LCD_WriteStringValue() ), and it showed 9A6.  This is where I got the 9A6 from.  I guess there's some simple explanation for this as well?

[allawtterb]

wareagle wrote:
Yes, that is what I thought originally.  However, I remembered the test I did where I had the NCB print its NWK address (more specifically, the value of gNwkData.aShortAddr) on the LCD (using LCD_WriteStringValue() ), and it showed 9A6.  This is where I got the 9A6 from.  I guess there's some simple explanation for this as well?

I am guessing that you type cast gNwkData.aShortAddr to an unsigned int when you called the function, like:

Code:

LCD_WriteStringValue("Network Address: ",(unsigned int)gNwkData.aShortAddr,0,gLCD_HexFormat_c);

 

Instead of dereferencing

Code:

LCD_WriteStringValue("Network Address: ",(*(unsigned int *)gNwkData.aShortAddr),0,gLCD_HexFormat_c);

 
The type casting to a pointer to an unsigned int might not be necessary, you might have just been able to derefence it with *gNwkData.aShortAddr.

Edit: Added source code blocks for better formatting

Message Edited by allawtterb on 2008-04-14 01:19 PM

[Mads]

Wareagle,

A coordinator can NOT have another address than 0x0000.

I can only recommend that you try and follow the step by step instructions of the Beestack Applications Develoment guide chapter 2, and then add the function i just supplied.

If it is not your transmission function that is "wrong" then you might have introduced a problem elsewere.

Br,

Mads