Getting Error "ZPS_vExtendedStatusSetCallback" as 0x80 and 0x85 when power off and power on JN5179.

[Mayankpatel]

Hi,

we are using ZigBee 3.0 stack and using SDK 4270 with a 1216 application.

When I power cycle the JN5179 chip getting extended status: 0x80 (ZPS_XS_E_NO_FREE_NPDU) and 0x85 (ZPS_XS_E_NO_FREE_MCPS_REQ) error.

We have configured NPDU as 30 from the .zpscfg file.

Is this error resolves by the stack after some time or we need to perform any action for this?

If this error does not resolve by the stack then please provide the solution to overcome this.

PS: In the Setup, when the Coordinator joined with 10-15 end-devices then and then getting an extended status error on every power cycle of the coordinator device.

[Mayankpatel]

Hi @mario_castaneda,

As per the configuration "Number of PDUs" is set to 30.

Is there any mechanism available in the stack to monitor the NPDUs used and free unused NPDUs.

If not, then please suggest us a solution to what to do when we face an error? how to handle that error?

Your help will be useful to us. 

[mario_castaneda]

Hi @Mayankpatel,

You could use the next API, it should be for debug purposes for the APDU used.

u8GetApduUsed

 Regards,

Mario

[Mayankpatel]

Hi @mario_castaneda,

Thanks for the reply.

I am facing an issue with the NPDUs used by stack and getting an error of NPDUs full when all devices in the network send the "Device Announce" message to the Coordinator.

Will you please share a possible solution for the same case when I observe "Extended status: 0x80"?

As I waited for half an hour but this error can't be handled by the JN Stack 4270. JN Stack stuck when I observe the same error and all devices were stopped communicating.

I don't know how to handle this case.

Please help us. Your help will be highly appreciated.

[mario_castaneda]

Hi @Mayankpatel,

Normally, if an application has run out of NPDU this will happen. There is no resource available, the packet will not be transmitted over the air. All of this is expected behavior from the Device.

If you can see from the debug logs that the extended status of either ZPS_XS_E_NO_FREE_NPDU, it indicates that there are not enough resources left for transmitting that command and thus it did not go over the air. It could be for the association response that the network could have.

Is it possible that you could keep the permit join as FALSE? This will exhaust the resources as Coordinator would be busy sending the association response for example. Probably, when you are trying to send a packet, as there are other nodes trying to join at the same time, sometimes the packet fails due to the resource issue.

Do you have any other periodic packets, reports that are sending at the same time?

Regards,

Mario

[Mayankpatel]

Hi @mario_castaneda,

Sorry for the late reply. 

We are only setting Permit Join as "True" when performing the device joining operation. once, device joining completes we are setting the Permit join as "False".

We are supporting the three types of end devices. all end-devices report data on such time intervals. but when all devices were power off and on at that time all devices send data to the coordinator at the same time.

Please guide us when we will face the error of "Extended status: 0x80" what will be the error handling mechanism?

As I go through the code and found the API "PDUM_eNPduFree(PDUM_thNPdu hNPdu);" which will free the NPDU. But I have a doubt that how can I access the handle of hNPDU from the application 1216?

Also, When we are facing these errors we are setting Permit join  "False" and power off all end-devices but the error is not recovering through the stack.

Your help will be beneficial for us as we are at a stage of production.

[mario_castaneda]

Hi @Mayankpatel,

Could you please confirm the next questions?

1) 0x80 error code is visible on Control Bridge or ZED that joined the network?

2) when does 0x80 error code visible: during ZED commissioning or after ZED joined the network?

3) power cycle only on Control Bridge without ZEDs been powered cycled?

Could you please provide the zpscfg and the console log file that has 0x80 error code dumped?

Regards,

Mario

[Mayankpatel]

Hi @mario_castaneda,

Thanks for the quick reply.

Please find below answers:

1) 0x80 error code is visible on Control Bridge or ZED that joined the network?

Ans: 0x80 error code is visible on the Control Bridge Side.

2) when does 0x80 error code visible: during ZED commissioning or after ZED joined the network?

Ans: Mostly 0x80 error code is visible when I power cycle the ZED and ZED Sends "Device Announce" Message to the Control Bridge. (after 4 to 5 retries of power cycle the ZED, Control Bridge stuck with the error code 0x80)

3) power cycle only on Control Bridge without ZEDs been powered cycled?

Ans: Here, I am power cycle the ZED not the Control Bridge.

Please refer attached .zpscfg file which we are using and also, refer to the attached logs when the error occurs.

[mario_castaneda]

Hi @Mayankpatel,

I hope you are doing great.

Did you power cycle all joined 15 ZEDs simultaneously or only power cycle single ZED?

Can you provide us the Ubiqua Log when power cycle ZED?

Which SDK version customer used for JN5179 and which application of their ZED?

JN5179 is not recommended for the Zigbee application and we are phasing out this chip. We know you are a design house working on this chip.

We should recommend them migrate their application to JN5189 as soon as possible. We don't release a new JN5179 Zigbee stack, but also the customer effort in case they want to put their design into production in the future.

Regards,

Mario

[Mayankpatel]

Hi @mario_castaneda,

Please find my answers below:

Did you power cycle all joined 15 ZEDs simultaneously or only power cycle single ZED?

Ans: I power cycled all joined ZEDs at the same time.

Can you provide us the Ubiqua Log when power cycle ZED?

Ans: Please find the attached new logs with the ubiqua logs captured when the error occured.

Which SDK version customer used for JN5179 and which application of their ZED?

Ans: We are Using JN-AN-1216 with JN-SW-4270 (Build 1841) for the control bridge and we are using  JN-AN-1217(router Template) for all ZEDs. We are using a router template because creating the mesh network through it.

[mario_castaneda]

Hi @Mayankpatel,

Thank you so much for the reply. We are working with the answers that you provided. However, we strongly recommended starting the process to migrate to the JN5189 device, this is our last MCU that supports ZigBee and also the support will be fast.

Regards,

Mario

[Mayankpatel]

Hi @mario_castaneda,

We are at a stage of production so we can't change the chip from JN5179 to JN5189.

we already completed the development and testing on this.

For sure, from the next time, we will ensure that we can use JN5189 instead of JN5179.

Your support will definitely help us. 

[mario_castaneda]

Hi @Mayankpatel,

We found a very strange behavior

Why is the ZR(0xB400) sending rejoin request which is only capable of ZED node?

this is not allow for ZR, what are the code modifications that you did?

Regards,

Mario

[Mayankpatel]

Hi @mario_castaneda,

We make the below changes in the application:

Function: BDB_vStart

            case ZPS_ZDO_DEVICE_ROUTER:
                ZPS_eAplZdoStartRouter(TRUE); //FALSE: Don't send Device Announce
                eInitState = E_INIT_IDLE;
                sBdbEvent.eEventType = BDB_EVENT_INIT_SUCCESS;
                APP_vBdbCallback(&sBdbEvent);
                break;

Function: APP_vBdbCallback

        case BDB_EVENT_INIT_SUCCESS:
		    DBG_vPrintf(TRACE_APP,"APP: BDB_EVENT_INIT_SUCCESS\n");
		    if (eNodeState == E_STARTUP)
		    {
			   eStatus = BDB_eNsStartNwkSteering();
			   DBG_vPrintf(TRACE_APP, "BDB Try Steering status %d\n",eStatus);
		    }
		    else
		    {
			   DBG_vPrintf(TRACE_APP, "BDB Init go Running");
			   eNodeState = E_RUNNING;
			   BDB_vRejoinCycle(TRUE);
			   PDM_eSaveRecordData(PDM_ID_APP_ROUTER,&eNodeState,sizeof(teNodeState));
		    }
		    break;

What will be the issue facing when ZR Device Sends "Rejoin Request" to the ZigBee Control Bridge?

[mario_castaneda]

Hi @Mayankpatel,

It seems that you are mixing the ZED and ZR behavior together.

Also, I still recommend moving on to the last Zigbee MCU JN5189.

Regards,

Mario

[Mayankpatel]

Hi @mario_castaneda ,

We can't change the JN5179 at this stage as we have completed testing and development on this.

Did you found the solution for the specific error?

[mario_castaneda]

Hi @Mayankpatel,

As the JN5179 has very limited support.

What we can suggest is first don't mixing ZR and ZED features together :

if you want to use the device as ZR, remove rejoin request message send from the ZR ;

if you want to use the device as ZED, remove the link status message send from the ZED.

Regards,

Mario

[mario_castaneda]

Hi @Mayankpatel,

I hope you are doing great. As you are working with the JN5179 device, it is not supported. Please get in contact with your local sales.

No free NPDUs (resource error) - the number of NPDUs is set in the "Number of NPDUs" property of the "PDU Manager" section of the ZPS Configuration Editor

In this case, you have to be careful of the number of PDUs that you are using and also you could also free the PDU instance that you are not using at that moment.

Regards,

Mario