MKW41Z ZigBee connection issues

[bogdan_kostiv]

Hi,

I'm working on a solution with ZigBee connectivity features. Target platform - MKW41Z512. A role of a device - an end device with a router capabilities. Coordinator is based on other platform (CC2520). Security settings - reconfigured link key. I used samples for MKW41Z512 as a base for the development.

Currently I' facing some issues with communication. The MKW41Z512 device initializes communication, it receives beacon and then starts association procedure. But this procedure fails when coordinator sends association response (successful):

sometimes I see that communication goes further but it reach maximum a Transport Key transmission:

I re-checked configuration several times but haven't found what can causes such an issue.

I also checked to connect the MKW41Z512 device to a MKW41Z512 - based coordinator. And in such setup everything works. I can see successful connection and communication. It seems like there are some issues during transmission data from  CC2520 to MKW41Z512.

My questions:

1. What setup/configuration may cause such behavior?

2. As I know, recommended bitrate fr 2.4G is 250 kbps for ZigBee, but I discovered that the PHY for MKW41Z512 sets 500 kbps as default value. I tried to use  250 kbps setup but in this case the MKW41Z512 device wasn't able to receive beacon from the CC2520 coordinator.

PhyPacketProcessor.c

PhyStateMashine.c:

BR,

Bogdan

[bogdan_kostiv]

In addition to previous information I have discovered that no matter what bitrate is selected for ZigBee the same configuration is used and it is 500 kbps.

fsl_xcvr.c:

I will be grateful for any comments regarding this issue.

BR,

Bogdan

[mario_castaneda]

Hi Bogdan,

This is a documentation issue. Please accept our apologies.

However, the Zigbee Specification mentions the is 250 kbps for communication. The example shows that was set up by 500 kbps but the KW41 is working on 250 kbps. 

We ran some test with other devices to see the interoperability.

Could you please look at the application that you are running on?

Regards,

Mario

[bogdan_kostiv]

Hi Mario,

Thank you for the reply. I also found information in MCU's datasheet that the bitrate is 250 kbps. On the other side a chip supports 250 kbps as well and it is the only option.

Unfortunately I haven't solved the issue yet. it seems like some timings issues. I added some debug print outs to a PHY layer and I see that ZigBee or MAC layer terminates communication too early:

I see just 2ms between switching to Rx mode in the PHY and notification that connection is not establishing from ZigBee.

At same time coordinator sends Association Response with larger delay (from 4 to 20 ms) since last ACK. And of course the PHY doesn't have chances to receive it.

I'm wondering if it possible to adjust this timings? I have found several defines in the code but they didn't fix the issue. Mentioned interval remains the same.

BR,

Bogdan

[mario_castaneda]

Hi Bogdan,

What is the Zigbee example that you are working on?

I will run some tests, but I do not have any TI wireless device, however, the Zigbee stack is compatible with other devices that are certified.

I added some debug print outs to a PHY layer and I see that ZigBee or MAC layer terminates communication too early:

As you know, the debug print requires some time and could affect the timings. However, the coordinator should return some value with the issue or should provide the reason why is not sending the transport key.

Does the device has the Zigbee Alliance key?

Regards,

Mario

[bogdan_kostiv]

Hi Mario,

I use hybrid BLE and ZigBee Router example from the SDK as a base for testing. I temporary added some minor modification to be able to use the example in test purpose.

Regarding debug printouts, I added RTT console for debug information print outs, but it performs data transferring to the RTT in a separate thread, and all messages go via queue to that thread. So, additional overhead should be minimal. Additionally I see that behavior is almost the same.

Both sides use the Zigbee Alliance key. But actually communication stops on the Association Response packet so the key shouldn't affect communication on such an early stage.

As I see communication fails due to failure in certain packets receiving on the NXP MCU side. It doesn't receive Association Response packets from the coordinator side so it doesn't confirm such data with ACK. So, coordinator stops further transferring. And I see that MAC or ZigBee implementation on NXP MCU side reports that communication is not successful quite early, Packets from my coordinator hasn't reach NXP MCU at that time

I tried to find function or defines to extend time for RX packets receiving, but I haven't got success. MAC and ZigBee are provided as a libraries, so I can't check the source code. Additionally I haven't found required information in datasheets.

It would be great to get some inputs how I can extend time for RX mode to provide required time frame for data receiving from the coordinator side.

BR,

Bogdan

[mario_castaneda]

Hi Bodgan,

I ran some tests by my side and sometimes the KW41 has some issues with the association process.

The Bluetooth LE stack has a higher priority. So, the Zigbee stack has some time for the association process, if the device is scanning all the channels. The Bluetooth stack is stoping the Zigbee task.

For example: bdb_options.h

#define SINGLE_CHANNEL 24

I am checking this with other tests. I recommend to select some specific channel and the device will connect without any issues. 

Please let me know if you have any issues with this.

Thank you for your feedback.

Regards,

Mario

[bogdan_kostiv]

Hi Mario,

Thank you for advises. They were useful but didn't solve the problem.

The root cause was in ACK reply from the coordinator side (a reply on data request packet from end device side). It should contain frame pending bit set to "1" to indicate that coordinator will transfer association response packet. In my case the coordinator don't set this flag and the end device just ignores association response packet. Everything works after fixing the coordinator side.

BTW, I have discovered commented source code in the PHY layer (for example in the PhyStaeMashine.c). It looks like it wasn't checked/reviewed properly before releasing. I would recommend to  review it.

BR,

Bogdan

[mario_castaneda]

Hi Bodgan,

Does the KW (Hybrid) example connect with your coordinator?

Thank you for the feedback. Did you uncomment some code? What is the specific file that you uncomment?

Regards,

Mario