Seeking Assistance with Reset Cause on nRF52840 DK

[jemalkorra]

Hello Nordic community,

I hope this message finds you well. I am currently working on a project using the nRF52840 DK, involving UART interrupts, timer interrupts, and Zigbee communication. I have implemented the hwinfo_get_reset_cause function to determine the reset reason, and I'm encountering a specific reset cause: RESET_SOFTWARE. Can anyone shed light on its implications and common scenarios leading to this reset cause?

Our project involves UART interrupts and timer interrupts for communication purposes. We aim to send and receive Zigbee messages, acting as a gateway by transmitting UART responses via Zigbee. Upon sending Zigbee APS payloads, we are observing a successful return, but unfortunately, the payload is not visible on the sniffer.

zb_ret_t ret = zb_aps_send_user_payload(bufid,

                                                    dst_addr,

                                                    ZB_profileid,

                                                    ZB_clusterid,

                                                    ZB_src_endpoint,

                                                    ZB_dst_endpoint,

                                                    ZB_APS_ADDR_MODE_16_ENDP_PRESENT,

                                                    ZB_FALSE,

                                                    outputPayload,

                                                    chunk_size);

if(ret == RET_OK) LOG_DBG("RET_OK - if transmission was successful scheduled;\n");

Are there any best practices or potential pitfalls when combining UART interrupts and timer interrupts on the nRF52840 DK for such communication tasks? Any insights or advice on optimizing the integration of these features would be highly valuable.

Best regards,

[Maria Gilje]

Hello,

You may find some answers to your question by reading section 5.3.6 of the nRF52840 Product Specification and studying the relevant source code for z_impl_hwinfo_get_reset_cause().

Also: which nRF Connect SDK version are you working with?

I will look more into your questions soon. I hope the links can get you started.

Best regards,

Maria

[jemalkorra]

Hi Maria,

Thanks for the quick help! I'll dive into section 5.3.6 of the nRF52840 Product Specification and check out the source code for z_impl_hwinfo_get_reset_cause.

I'm using nRF Connect SDK version 2.5.1.

If you happen to come across any additional insights or resources regarding software resets, I would greatly appreciate your guidance.

Best regards,

[jemalkorra]

Hello Maria,

I hope you're doing well. I have still the same issue. The app restarts and I don´t know how to fix it. Can you provide me:

1. Examples of zb_aps_send_user_payload: I'm looking for some practical examples or usage scenarios of the zb_aps_send_user_payload function. Can anyone provide some straightforward examples or direct me to resources where I can find them?

2. Handling Pointers in Interrupt Contexts: Additionally, my project involves UART interrupts, timer interrupts, and Zigbee communication. I'm wondering if there's a need to protect the access to pointers, such as outputPayload, when handling these interrupts simultaneously. Are there any precautions or best practices I should follow to ensure the stability of my system?

Any insights or advice would be greatly appreciated.

Thank you!

Best regards,

[Maria Gilje]

Hello,

I will look for some examples and get back to you shortly.

Best regards,

Maria

[jemalkorra]

Hi Maria,

Thank you for your attention to this issue.

We'd like to provide an update on this ticket as we've made some changes that appear to have resolved the problem. Initially, we were encountering unexpected resets, and after investigating, we suspected that the issue might be related to how we were handling buffer allocation and deallocation.

To address this, we revised our algorithm as follows:

1. We allocate a buffer (bufid) using zb_buf_get_out().
2. We send the APS payload using zb_aps_send_user_payload() and check if the return value (ret) indicates success.
3. We free the buffer using zb_buf_free(bufid) if it was allocated.

However, we noticed that the unexpected resets persisted, especially after freeing the buffer. To mitigate this, we made a modification to the algorithm. Now, before allocating a new buffer, we first check if bufid is already allocated. If it is, we reuse the existing buffer using zb_buf_reuse(bufid). Otherwise, we allocate a new buffer using zb_buf_get_out().

We believe that by reusing the buffer when possible, we might prevent unexpected resets that occurred after freeing the buffer.

Does this approach make sense to you? Have you encountered similar issues with the zb_buf_free() function in the past?

Looking forward to your feedback.

Best regards,