how to solve the status code error ZPS_APL_ZDP_E_NOT_PERMITTED in zigbee 3.0 stack

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

how to solve the status code error ZPS_APL_ZDP_E_NOT_PERMITTED in zigbee 3.0 stack

1,291 Views
jay_prajapati
Contributor I

Basic details.

controller                      : JN5169.

Zigbee version             :  3.0.

Stack                            : JN-SW-4170
build version                 : 1840.

Application Template    : JN_AN_1217.

i have configure the JN_AN_1217 application for normal sleep after the device has joined the network.

when coordinator is powered off and, if the joined device try to sends the data to coordinator after wake from normal sleep(Ram On & Osc off).

But due to synchronization loss end device try to search for parent but parent is powered off rejoin failure event occurs on end device side.On rejoin failure event i put the device in normal sleep again(Ram On & Osc off).

When End device again wake from normal sleep(Ram On & Osc off) for sending respective data, first poll request is fired but in return status i get ZPS_APL_ZDP_E_NOT_PERMITTED(0x8b) and end device is not even try to rejoin.

for solution i haved to soft reset the device then only i can send any request out.

if some body have come across this type of error and solved with some other way let me know in reply.

Labels (1)
0 Kudos
Reply
3 Replies

1,062 Views
jay_prajapati
Contributor I

Hi Mario,
No i have not put the coordinator in sleep i have just powered off.
Note:
1. Coordinator is not configure for sleep.
2. End device is configure for normal sleep after its joined the network.
Now i was examining a scenario, if coordinator is powered off and End device try to send data but not able to communicate, then stack try to recover it automatically(BDB feature).
Note:
Here End device is already a part of network and in normal sleep mode(Ram on & Osc off).
so in 1st instance the End device wake from normal sleep and try to send the data, but unfortunately not able to communicate with Coordinator.
In the above instance when End device wake form sleep(ways of wake eg. Dio trigger or wake timer) as per flow the End device trigger poll request to Coordinator API get success but stack get internally that it has lost
the communication with gateway it will trigger failure recovery of the network automatically but it don't find the coordinator and BDB_EVENT_REJOIN_FAILURE is generated by stack and as soon as i get this event i putting the
end device into normal sleep.

Now in 2nd instance the End device wake from normal sleep(ways of wake eg. Dio trigger or wake timer) as per flow the End device trigger poll request to Coordinator, but API get fails and returns with status code
ZPS_APL_ZDP_E_NOT_PERMITTED(0x8b) and data sending API also get fails and stack doesn't even trigger network rejoin proccess and i per program flow End device goes to normal sleep.

Now Coordinator is powered again and End device wake from normal sleep(ways of wake eg. Dio trigger or wake timer) as per flow the End device trigger poll request to Coordinator, but API get fails and returns with status code
ZPS_APL_ZDP_E_NOT_PERMITTED(0x8b) and data sending API also get fails and stack doesn't even trigger network rejoin process.
Now in above instance the gateway is power but the end device not able to communicate.

My concern is why End device is not able to communicate ?
Regards,
Jay.

0 Kudos
Reply

1,062 Views
mario_castaneda
NXP TechSupport
NXP TechSupport

Hi Jay,

If the ED is not able to rejoin to the network, the ZigBee Base Device makes a series of rejoining attempts.

in which case a join through Network Steering is attempted.

Please look at the ZigBee 3.0 Devices User Guide:

-If the node was in a network:

Regards,

Mario

0 Kudos
Reply

1,062 Views
mario_castaneda
NXP TechSupport
NXP TechSupport

Hi Jay,

First of all, we do not recommend to have the coordinator in sleep mode. 

Did you capture the packets in the air? The end device should be looking for his parent, and the sniffer should see this packet.

Regards,

Mario

0 Kudos
Reply