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,

[Maria Gilje]

Hello,

Thank you for your patience with this.

jemalkorra said:

We'd like to provide an update on this ticket as we've made some changes that appear to have resolved the problem.

Thank you for updating and great to read that you have found a possible solution.

A couple of notes about your solution:

jemalkorra said:

• We send the APS payload using zb_aps_send_user_payload() and check if the return value (ret) indicates success.
• We free the buffer using zb_buf_free(bufid) if it was allocated.

zb_aps_send_user_payload returns RET_OK when the sending has successfully been scheduled. Freeing bufid right after may result in the bufid being freed before the payload has been sent.

jemalkorra said:

If it is, we reuse the existing buffer using zb_buf_reuse(bufid).

Same root point as above -- the bufid may still be in use and reusing it can overwrite the existing data.

Other than that the solution looks good.

jemalkorra said:

Have you encountered similar issues with the zb_buf_free() function in the past?

We have not, as far as I can tell from our internal tickets and from speaking to a colleague.

I want to address your previous questions as well, since they are currently not commented on.

jemalkorra said:

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?

See this reply which describes the role of the function.

jemalkorra said:

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?

See Zephyr's Thread Priorities section from the Threads page and the Interrupts page.

Best regards,

Maria

[jemalkorra]

Thanks Maria,

Yes, we could see that we could not guarantee that the payload had been sent before reusing the buffer. But then... What would be the appropriate way to free the buffer, so we can be sure that the payload has been sent?

I can see that we can use using zb_aps_set_user_data_tx_cb() to set a callback function to notify the results of transmitting an APS frame with user payload. We could define a callback function that simply frees the buffer. Do you think this would work? If not, I would be grateful if you could point me in the right direction to free the buffer.

Beste regards,

[Maria Gilje]

Hello,

jemalkorra said:

I can see that we can use using zb_aps_set_user_data_tx_cb() to set a callback function to notify the results of transmitting an APS frame with user payload. We could define a callback function that simply frees the buffer. Do you think this would work? If not, I would be grateful if you could point me in the right direction to free the buffer.

Yes, this should work fine!

Best regards, Maria