• State Verified Answer
  • Locked Locked
  • Replies 9 replies
  • Subscribers 74 subscribers
  • Views 1786 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 286309
Options
Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs
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

handling PM_CONN_SEC_ERROR_SMP_TIMEOUT

byves

Hey.

In production we are logging PM error events to try to determine the root cause for some unstable connection that keep showing up.
We are seeing with high occurrence error code 4353 which is the SMP timeout.
This is often found when reported unstable connections or failure to start OTA DFU.

From the Bluetooth Core:


From Nordic Info Center:

#define 	PM_CONN_SEC_ERROR_SMP_TIMEOUT   (PM_CONN_SEC_ERROR_BASE + 0x101)
/* Pairing/bonding could not start because an SMP time-out has already happened on this link.
* This means that no more pairing or bonding can happen on this link. 
* To be able to pair or bond, the link must be disconnected and then reconnected. 
* See Bluetooth Core Specification 4.2 section 3.H.3.4 (Bluetooth Core Specification).
*/


Can you provide the advised strategy to recover a stable BLE link whenever this occurs?

SDK: 17.0.2
SD: s140 - 7.2.0
bluetoothctl: 5.48

  • 0 in reply to Edvin

    I understand your point and I am quite aligned with it. The BLE management when app is in background could be enough to explain the difference between iOS and Android

    However there's this specific case where our clients are asked to be close to the device and the app is on foreground to perform OTA DFU. It happens that sometime we get complaints that DFU is unstable or just hard to perform and this PM error can be seen in some of those reports.

    Can you think of any situation where this might happen?

  • 0 in reply to byves

    Well, the nRF will reset during a DFU session (several times). This is expected, but if you have some custom app not expecting that, it may be "surprised". I don't know.

    Edvin said:
    Do you know exactly where in the application this error code shows up? Is it as a return value from a function call on the nRF? Or does it show up in your app?

    Do you know this?

    BR,

    Edvin

  • 0 in reply to Edvin

    its a return value from a function call on nRF

  • +1 in reply to byves

    So what call is it? Do you know, or doesn't it say in the report?

    I can't really say much more than what I already did. I guess it is calling some function that returns PM_CONN_SEC_ERROR_DISCONNECT. As the description of that value says:
    "Pairing or encryption did not finish before the link disconnected for an unrelated reason."

    So the devices are disconnected when this occurs, and it is not the reason for the disconnect (at least not from the nRF's side). 

    BR,

    Edvin

Related
Terms of service