This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Sending data while there is frequent ble connection and disconnection due to week signal causes wdog reset

Hi, we are using nrf sdk15.0.0 in the application. There are two nrf devices 52840. one is central, other is peripheral. Continuously data is sent from one device to another as notification. When the distance between the two devices are increased after some distance of greater than 10 meters frequent connection disconnection happens and there is packets loss. During such scenario the firmware seems to be stuck and causes wdog reset. What are the conditions that could trigger wdog reset in such scenarios? 

When wdog is set to high priority, the reset did not occur, but device is continuously advertising and other low priority tasks are blocked.

Please clarify

Parents
  • Thanks for response. Supervision timeout is set to 4sec. Today we could narrow down the scenario causing the issue. The issue occurs when there is data to be transmitted and a sudden disconnect happens.

    A periodic function is called to transmit multiple packets of data in a loop in the application while the p_ctx->busy is false. p_ctx->busy is set when sd-ble-gatts-hvx returns error code NRF_ERROR_RESOURCES.

    The wdog timeout is set to 20sec. If the device gets connected before wdog reset occurs then the application resumes and does not reset. However if it is not connected within this time, then wdog reset occurs.

    Any suggestions on the cause of reset would be helpful

  • Hi Karl, issue still exists. The softdevice seems to  hang after disconnect and never returns to application.

  • Hello,

    Vijay.Krish said:
    Thanks for response.

    No problem at all, I am happy to help!

    Vijay.Krish said:
    Supervision timeout is set to 4sec. Today we could narrow down the scenario causing the issue. The issue occurs when there is data to be transmitted and a sudden disconnect happens.
    Vijay.Krish said:
    The wdog timeout is set to 20sec.
    Vijay.Krish said:
    A periodic function is called to transmit multiple packets of data in a loop in the application while the p_ctx->busy is false. p_ctx->busy is set when sd-ble-gatts-hvx returns error code NRF_ERROR_RESOURCES.

    Thank you for clarifying - this is very helpful information!
    This sounds a lot like a application-layer logic issue. Could you elaborate thoroughly or share a code snippet of the section in which this conditioned p_ctx->busy loop is taking place?
    How is this looping implemented? I imagine that the SoftDevice disconnects and finishes all its processes here, but the application is still trying to send data and is thus stuck in this loop. Since no data is being sent, the loop never ends, and then the watchdog resets the device.
    Could you perhaps try to clear your p_ctx flag as part of the ble_evt_handler's disconnect event handling?
    I suppose you should also have the disconnect event start with placing un-transmitted data back in the buffer/queue for future transmits, to avoid loosing the data.

    Please keep in mind that I have not actually seen any code for this section, so this is just my initial thoughts and speculations based on the information in your previous answer.

    Looking forward to resolving this issue together!

    Best regards,
    Karl

Reply
  • Hello,

    Vijay.Krish said:
    Thanks for response.

    No problem at all, I am happy to help!

    Vijay.Krish said:
    Supervision timeout is set to 4sec. Today we could narrow down the scenario causing the issue. The issue occurs when there is data to be transmitted and a sudden disconnect happens.
    Vijay.Krish said:
    The wdog timeout is set to 20sec.
    Vijay.Krish said:
    A periodic function is called to transmit multiple packets of data in a loop in the application while the p_ctx->busy is false. p_ctx->busy is set when sd-ble-gatts-hvx returns error code NRF_ERROR_RESOURCES.

    Thank you for clarifying - this is very helpful information!
    This sounds a lot like a application-layer logic issue. Could you elaborate thoroughly or share a code snippet of the section in which this conditioned p_ctx->busy loop is taking place?
    How is this looping implemented? I imagine that the SoftDevice disconnects and finishes all its processes here, but the application is still trying to send data and is thus stuck in this loop. Since no data is being sent, the loop never ends, and then the watchdog resets the device.
    Could you perhaps try to clear your p_ctx flag as part of the ble_evt_handler's disconnect event handling?
    I suppose you should also have the disconnect event start with placing un-transmitted data back in the buffer/queue for future transmits, to avoid loosing the data.

    Please keep in mind that I have not actually seen any code for this section, so this is just my initial thoughts and speculations based on the information in your previous answer.

    Looking forward to resolving this issue together!

    Best regards,
    Karl

Children
No Data
Related