JN516X Dump Stack problem and Deep Sleep

[ffonck96]

Hi y'all.

I have an issue regarding sending-receiving data between EndDevice and Coordinator. Somehow, im getting a Dump Stack from my program when i receive a broadcast message at the precise moment when i'm sending data. I have been investigating deep sleep related content, such as PWRM_eScheduleActivity() and PWRM_u16GetActivityCount().

At the moment, the code in every cycle runs at the end a PWRM_eScheduleActivity() before going to sleep. Eventually, it starts sending data. The error occurs when is sending data and changing accordingly the application FSM, here the broadcast is receive in a poll data function ZPS_eAplZdoPoll().

There's a way to avoid going to sleep when some events are occurring, just like broadcast and SEND_DATA?

I'm relying on JN-AN-1229-ZBPro-Application-Template with the change that my app can schedule an activity and go to deep sleep. Also, in order to send data it has to wait 600ms in the process, this is way it has a finite state machine, so it can wait on the while True cycle.

I hope this information is enough. What gives?

[EduardoZamora]

Hello @ffonck96

Hope you are doing well.

Please, consider that JN5189/88T is preferred for any new Zigbee design.

As I understand, you are experiencing some unexpected behaviors while transferring data to a sleeping End Device, is this correct? If that is the case, perhaps you may some useful information in the ZigBee 3.0 Stack User Guide (which can be found in JN516x/7x Zigbee 3.0 webpage), Section 5.5.3 Polling for Data; and Appendix B.2 Sending data to Sleeping End Devices.

If my understanding is not correct, or if this information is not what you are looking for, please let me know.

Regards,
Eduardo.

[ffonck96]

Hi @EduardoZamora thanks for your reply.

Please, consider that JN5189/88T is preferred for any new Zigbee design.

Unfortunately, i cannot use the JN5189/88T because of client/project restrictions. So I'm forced to work on the JN5168.

As I understand, you are experiencing some unexpected behaviors while transferring data to a sleeping End Device, is this correct? If that is the case, perhaps you may some useful information in the ZigBee 3.0 Stack User Guide (which can be found in JN516x/7x Zigbee 3.0 webpage), Section 5.5.3 Polling for Data; and Appendix B.2 Sending data to Sleeping End Devices.

You are right. I'm gonna take a look of it. Thanks for the information, i haven't seen yet until now.

Regards!

[ffonck96]

I managed to stop a little the stack dump. But another dump error appeared:

(16:42:57.593) <CR>Unclaimed Interrupt at priority 0
(16:42:57.593) u32PICMR = 0 : u32PICSR = 0
(16:42:57.593) u32PICMSR = 0 : u32IPMR = 0
(16:42:57.593) u32IHPR = 0 : u32AINT = 0 u32PINT 0
(16:42:57.593) EPCR = 89a4d : EEAR = 6b1e7fb7
(16:42:57.593) Stack dump:
(16:42:57.593)  4007b68 : 00000000
(16:42:57.593)  4007b6c : 00089a6e
(16:42:57.593)  4007b70 : 6b1e7fb7
(16:42:57.593)  4007b74 : 00000000
(16:42:57.593)  4007b78 : 00000000
(16:42:57.593)  4007b7c : 00000000
...