• State Verified Answer
  • Replies 5 replies
  • Subscribers 89 subscribers
  • Views 1201 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 265822
Options
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

Vijay.Krish

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
  • +1

    Hello,

    frequent connection disconnection happens and there is packets loss.

    How long have you defined your connections timeout parameter to? If you are expecting packet loss due to long distance / noisy environment, you may want to increase the timeout to reduce the frequent disconnections and reconnections.

    During such scenario the firmware seems to be stuck and causes wdog reset.

    Are there any errors being returned, or other indication of something going wrong during the reconnection?
    The SoftDevice takes priority over any application-layer process, and it will do so whenever a timing-critical BLE task needs handling. In the case of rapid disconnections and reconnection, the SoftDevice will spend more time actively controlling the radio.
    However, it does not take very long to establish these connections, or handle the disconnects, so I am thinking that your watchdog timeout might be too short. What do you mean when you say that the firmware gets 'stuck' - how long specifically is the device seemingly doing nothing?

    When wdog is set to high priority

    What priority did you set the to, and why would you raise its priority? Raising the priority of the watchdog somewhat defeats its purpose. 

    What are the conditions that could trigger wdog reset in such scenarios? 

    The watchdog only has a single condition for triggering a reset, and that is if it stops being fed.
    The watchdog is usually fed in the main context, to ensure that the application does not get stuck somewhere in an infinite / very long interrupt handling. What is your current watchdog timeout set to? It sounds to me like you should increase the watchdog timeout, if it keeps triggering because the SoftDevice has to keep reconnecting to the other device.

    but device is continuously advertising and other low priority tasks are blocked.

    The lowest possible advertising interval is 10 ms + a random delay of 0 - 10 ms. You should therefore have ample time between advertisements to process other events. What else is your application doing in between advertisements? Could it be that you have a higher-priority task that does not return, and therefore the low-priority tasks does not get to run?

    Looking forward to resolving this issue together!

    Best regards,
    Karl

Reply
  • +1

    Hello,

    frequent connection disconnection happens and there is packets loss.

    How long have you defined your connections timeout parameter to? If you are expecting packet loss due to long distance / noisy environment, you may want to increase the timeout to reduce the frequent disconnections and reconnections.

    During such scenario the firmware seems to be stuck and causes wdog reset.

    Are there any errors being returned, or other indication of something going wrong during the reconnection?
    The SoftDevice takes priority over any application-layer process, and it will do so whenever a timing-critical BLE task needs handling. In the case of rapid disconnections and reconnection, the SoftDevice will spend more time actively controlling the radio.
    However, it does not take very long to establish these connections, or handle the disconnects, so I am thinking that your watchdog timeout might be too short. What do you mean when you say that the firmware gets 'stuck' - how long specifically is the device seemingly doing nothing?

    When wdog is set to high priority

    What priority did you set the to, and why would you raise its priority? Raising the priority of the watchdog somewhat defeats its purpose. 

    What are the conditions that could trigger wdog reset in such scenarios? 

    The watchdog only has a single condition for triggering a reset, and that is if it stops being fed.
    The watchdog is usually fed in the main context, to ensure that the application does not get stuck somewhere in an infinite / very long interrupt handling. What is your current watchdog timeout set to? It sounds to me like you should increase the watchdog timeout, if it keeps triggering because the SoftDevice has to keep reconnecting to the other device.

    but device is continuously advertising and other low priority tasks are blocked.

    The lowest possible advertising interval is 10 ms + a random delay of 0 - 10 ms. You should therefore have ample time between advertisements to process other events. What else is your application doing in between advertisements? Could it be that you have a higher-priority task that does not return, and therefore the low-priority tasks does not get to run?

    Looking forward to resolving this issue together!

    Best regards,
    Karl

Children
No Data
Related