• State Verified Answer
  • Replies 5 replies
  • Subscribers 73 subscribers
  • Views 750 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 244679
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Please more information about "the" confirmed bug in Timeslot API

rgrr2

Hello

in the thread about NUS connection problems with TimeSync example ported to SDK16.0.0 Sigurd confirms a bug in the timeslot API.

Could you please be more specific about this one?  What is the actual effect/cause of the bug?  Any (effective) workaround?  Bugfix planned?

Background is, that we observe some Timeslot API "anomalies" as well and are wondering if those are triggered by a bug in the timeslot API.  See here

Thanks for any information

Hardy

Parents
  • 0

    Hi,

    Background is, that we observe some Timeslot API "anomalies" as well and are wondering if those are triggered by a bug in the timeslot API

    Did you use S140 v6.1.1? If you test with S140 v6.1.0, and still see the "anomalies", then you have a different issue.

  • 0 in reply to Sigurd

    Hi Sigurd,

    thanks for the reply.  But to be honest: it does not make me happy because some important points are left unanswered.  E.g. what is the actual effect/cause of the bug and what are possible workaround.

    Trust me, we have spent a lot of time to get parallel protocols working and we are really interested in any assistance concerning is it "our" fault or "yours".  So a hint in the direction "this internal bug causes this and that behaviour and the workaround could be..." would be very helpful.

    Hardy

  • +1 in reply to rgrr2

    This scheduling bug was just recently discovered, it's still under investigation and not all details are fully known yet. What we know today is that a timeslot with NRF_RADIO_HFCLK_CFG_XTAL_GUARANTEED is causing the first packet sent by the master after CONNECT_IND packet to be sent a tiny bit too early, so that the slave misses this packet. (this is during BLE connection establishment). Both devices get a disconnect event with BLE_HCI_CONN_FAILED_TO_BE_ESTABLISHED. This is the only known effect of the bug today. If you read the other post, I have provided several potential workarounds. E.g. start the timeslot session after the BLE scanning is started, or e.g. use NRF_RADIO_HFCLK_CFG_NO_GUARANTEE + sd_clock_hfclk_request() instead. And yes, we will fix this bug in a future release.

Reply
  • +1 in reply to rgrr2

    This scheduling bug was just recently discovered, it's still under investigation and not all details are fully known yet. What we know today is that a timeslot with NRF_RADIO_HFCLK_CFG_XTAL_GUARANTEED is causing the first packet sent by the master after CONNECT_IND packet to be sent a tiny bit too early, so that the slave misses this packet. (this is during BLE connection establishment). Both devices get a disconnect event with BLE_HCI_CONN_FAILED_TO_BE_ESTABLISHED. This is the only known effect of the bug today. If you read the other post, I have provided several potential workarounds. E.g. start the timeslot session after the BLE scanning is started, or e.g. use NRF_RADIO_HFCLK_CFG_NO_GUARANTEE + sd_clock_hfclk_request() instead. And yes, we will fix this bug in a future release.

Children
Related
Terms of service