How to debug STM32WB55 Zigbee application ?

[APEYR]

Hello,

I'm working on a project using Zigbee as main communication network.

In this project we develop two devices :

• One as server and coordinator
• One as client and router

We based our hardware on STM32WB5MMG.

I used the examples of Zigbee_OnOff_Client_Router and Zigbee_OnOff_Server_Coord to understand how to develop our application.

I'm actually stuck at a point where mu client router cannot connect to the coordinator and the join status is ZB_APS_STATUS_SECURITY_FAIL.

I don't know how to solve this error, the preconfiguredLinkKey are the same, exactly as in the examples.

I think the problem come from the coordinator because if I use the coord example in a nucleo board, my router device is able to connect to it... but I haven't been able to find th differences between my coord and the example and I can't find a lot of documentation on how to debug this kind off errors.

Can anybody help me ?

Thanks in advance and have a nice day.

[pdelrot]

Hello,

I have this behavior daily during my design phase : ZB_APS_STATUS_SECURITY_FAIL during join.

Each time a restart the software to test, I can't join the network, because the node previously joined it during the last debug session.

I have to :

• power off my board
• delete the note from my network through the coordinator interface (RPi4 + Phoscon RaspBeeII module)
• restart

A bit painfull, waiting myself the design the network storing and rejoin features (there are examples for this).

Regards,

Pascal

[Remi QUINTIN]

As far as I understood issue does not occurs if Nucleo boards are used. The issue occurs with STM32WB5MMG.

Looking at some other comments, observed behavior may be linked to replay attack protection mechanism.

If Router is reset several times, ZC will no more accept Join request as NWK Security Counters are out of range.

Only way to make it working is either to reset ZC or implement persistency on Router side.

As usual getting a Wirehshark log will definitely help.

[pdelrot]

Hello, sure, if persistence (as ST examples) or similar (Zigbee network parameters) with ZbRejoin behavior, this not happening.

I had the time to add this feature, works well,

Such security protections are mandatory, but could be annoying at first for beginners or during design.

To avoid the persistence mecanism, or replace it by a similar behavior, these values could be stored securely and reused with ZbRejoin.

Pascal

 //! Zigbee network parameters, to be read after successfull join, and reused for ZbStartTypeRejoin
 enum ZbStatusCodeT status;
 struct ZbChannelListT channel;
 uint16_t network_pan_id;
   uint64_t network_extented_pan_id;
 uint16_t desired_short_addr;
 uint64_t zb_mac_addr;
 
 status = ZbNwkGet(zigbee_app_info.zb, ZB_NWK_NIB_ID_ActiveChannelList, &channel, sizeof(channel));
  read_zigbee_params.channel_mask = channel.list[0].channelMask;
 
 status = ZbNwkGet(zigbee_app_info.zb, ZB_NWK_NIB_ID_PanId, &network_pan_id, sizeof(network_pan_id));
 
 status = ZbNwkGet(zigbee_app_info.zb, ZB_NWK_NIB_ID_ExtendedPanId, &network_extented_pan_id, sizeof(network_extented_pan_id));
 
 desired_short_addr = ZbShortAddress(zigbee_app_info.zb);
 
 zb_mac_addr = ZbExtendedAddress(zigbee_app_info.zb);