Z-Stack: Router can't join to network

You will find error codes listed in the ZComDef.h file.

For your error, 0xE9, it lists: #define  ZMacNoACK  0xe9

Thanks for reply,

This error would suggest that there was no ACK received for the join packet.

I looked further into the ZDApp.c and noticed that the coordinator enters the ZDO_JoinIndicationCB(), and also checked in mac_rx.c for the function that handles ACKs (its rxStartIsr
() I think). There's a section that generates ACK, by sending a strobe (either 0x0A or 0x0B) to my cc2420 transceiver and it seems to work fine. 

Is it possible to send a simple packet to the coordinator without joining the network? (just to test the communication and ACK's) If yes, which function should I use to do so?

Or maybe you have some other suggestions?

Let me ask you a couple of questions:

(1) Which ZStack are you using (1.4.3, 2.0.0, etc), on what platform (CC2430, MSP)?

(2) Are you sure that Coordinator and Router are on the same channel, using the same PanID?

I'm using ZStack 2.1.0 running msp430f2418 and cc2420 on a custom  board (but cc2420 is CC2420EM from TI).

I used GenericApp as template and modified only the reqiured files (hal_board_cfg.h, hal_mac_cfg.h).

They'are definately on the same channel because the router only tries to join when the coordinator is online. If I turn him off, the router stops join attempts. I also checked that the router detects that announce frame correctly.

Both devices have the same PANID defined in f8wConfig.cfg (equal to 0x0123)

Hmmm, this must be a ported MAC then. Where did you get the MAC code for the CC2420, from a previous ZStack release or from TIMAC?

If I understand correctly, the Router is receiving beacons from the Coordinator?

Are you using a sniffer to observe what's going on over-the-air?

Ok... basically I found 2 kinds of ZStack releases... One for CC2520 + MSP430f2618 the other for CC2420 + MSP430FG4618.

I couldn't find any for my config, so I thought that these must be almost identical. From what I remember I replaced the MAC folder contents and changed the SPI init (46xx has different register names), so the spi would be configured in the same way, hoping it would work. :-)

As for the sniffer, I have only 2 boards at the moment and would need to assemble the third for the packet sniffer. Or don't I?

Maybe I should port the stack differently?

Sorry, but a couple of more questions:

Are you using DCO or an external xtal?

What clock rate are you using? The F2618 code was tested at ~6 Mhz. Early attempts to run slower than that resulted in missed ACKs.

I changed the clock to run code from 8Mhz External crystal on XT1 port, The peripherials are run from DCO also set to 8MHz. I know it would be better if the crystal was on XT2, but I didn't know that when the board was designed.

Is it possible to use the stack designed for 4618 on my microcontroller? The main difference is that 2618 doesn't have the RTC module, and I'm not sure it is actually used in this stack version.

------

edit:

Does the 2.0.0 version support ZIGBEE-PRO features?

edit:

It seems there is a definable ZIGBEEPRO, so it would suggest it supports it.

Beacuse it seems to be the bad porting problem, I'm now trying to port the ZStack again, this time using only version 2.0.0 and modifying only in necessary places (i. e. where the complier/linker throws errors).

Yes, 2.0.0 (and later) support ZigBee-PRO. Yes, the compile flag ZIGBEEPRO enables the PRO features -- your project must also use the PRO libraries if you use this compile flag.

I was abscent for a week, but now I back and finished the new port of Z-Stack.

After new porting, the problem stayed.

However, I continued to search for the reason of the NO_ACK status. During the search, I inserted a breakpoint in the macSfdIsr(void) function (located in mac_sfd.c). The weird thing is, that when I just click it to just continue running, after several entrances to this ISR, the ZDO_JoinConfirmCB is called (which is expected), but the status returned in this function is Z_SUCCESS (i.e. 0x00), and the router joins the network.

This would suggest a problem with timing. Is there a definable ack wait time?

edit:

I found a MAC_ACK_WAIT_DURATION in mac_api.h, but changing it to a larger number didn't help.

edit:

Didn't find any definable time, but I found the macDualchipTxRequestAckTimeoutCallback function (located in mac_dualchip_tx.c) and just added a few hundreds (300 sufficed) to the time. Voila! It worked and the router joins the network.

If I find some time (I'm behind the schedule because of this problem), I will try to find a better solution to this problem (something with Mac Timer maybe), which can be caused by major changes in my clock configuration.

P.S. Thanks for your help xyzzy.