• State Verified Answer
  • Locked Locked
  • Replies 4 replies
  • Subscribers 62 subscribers
  • Views 646 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 276821
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Application-layer avoidance of DRGN-9612?

Elias

Hi,

My application is currently using s132 v5.1.0. The Release notes for s132 v6.0.0 say:

"Fixed an issue where incorrect timing calculations during the LE Data Length Update procedure could lead to an assert."

Upgrading the SoftDevice is very difficult at our stage of development, so we would like a way to avoid this by compensating in our application.

If the Central requests a Data Length Update, how can the application avoid the conditions that cause this issue? I've tried calling "sd_ble_gap_data_length_update(connHandle, NULL, NULL);", but I'm not sure whether using automatic values will reliably prevent the assert.

Parents
  • 0

    Hi,

    Have you experienced this issue or are you asking theoretical about this issue?

    The assert due DRGN-9612 will only happen if the TX DLE length is downgraded, while SoftDevice is trying to send a long packet (and gets a NACK at the same time). The issue was found internally and fixed. I consider this a very specific corner case issue that we have not seen any direct report of, since it's not very probably that a peer may ever downgrade its DLE length. At least we have not been able to tie it as the direct root-cause for any asset reported, however the assert that could happen is a generic "rem overstay" assert, so it might have occured without our knowledge though. All that said, the sd_ble_gap_data_length_update(connHandle, NULL, NULL) should be able to prevent this, since it always use the same length.

    Best regards,
    Kenneth

  • 0 in reply to Kenneth

    Okay, because our application always uses "max_tx_octets = 251", it sounds like the issue can't explain any of the unexpected resets (due to SD assert) that we've been seeing. Does that conclusion sound valid?

    We have another explanation for the resets, but it doesn't fit as "neatly" for all recorded instances, so we were exploring other possibilities.

  • +1 in reply to Elias
    Elias said:
    Okay, because our application always uses "max_tx_octets = 251", it sounds like the issue can't explain any of the unexpected resets (due to SD assert) that we've been seeing. Does that conclusion sound valid?

    I agree. You might have shared this in other devzone cases, but which asserts are you seeing and are they always the same?

Reply
  • +1 in reply to Elias
    Elias said:
    Okay, because our application always uses "max_tx_octets = 251", it sounds like the issue can't explain any of the unexpected resets (due to SD assert) that we've been seeing. Does that conclusion sound valid?

    I agree. You might have shared this in other devzone cases, but which asserts are you seeing and are they always the same?

Children
  • 0 in reply to Kenneth

    Unfortunately, we've only been able to retain information from SD asserts very recently in development, so for most instances, we don't have information on which assert fired. For the ones that we've captured, they are always "id = 0x01, pc = 0x15022", and we believe this is due to DRGN-9535 and DRGN-9723.

Related