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

[Edvin]

Hello,

Error (decimal)4352 = 0x1100, which would be the PM_CONN_SEC_ERROR_DISCONNECT (from peer_manager_types.h). 

So if you are struggling with disconnects, I think this is not a reason from the disconnects, but a consequence from the disconnect.

If you see this error, it suggests that the application running on the device seeing this error is at least still running, meaning it didn't crash/reset.

On what device are you seeing this error? The peripheral or the central? And what are you connected to? Another nRF or a mobile phone?

Do you see the event BLE_GAP_EVT_DISCONNECTED from your ble_evt_handler() (probably in your main.c file)? If so, what is the reason? If it doesn't say by default, you can check it using:

        case BLE_GAP_EVT_DISCONNECTED:
            NRF_LOG_INFO("Disconnected, reason %d.",
                          p_ble_evt->evt.gap_evt.params.disconnected.reason);
            m_conn_handle = BLE_CONN_HANDLE_INVALID;
            break;

Best regards,

Edvin

[byves]

Hi, thanks for your prompt reply.

I can confirm that the device doesn't crash and still runs after this error.
I'm seeing this error in peripheral devices connected to mobile phones (iOS and Android).

The following table shows the PM errors we are logging from our devices on the field:

when one device starts getting 4352 it keeps showing. The following table is a log from a single device and the UNEXPECTED PM EVENT is always 4352. Here you can see it pop out every few minutes.

While this happens a lot on the field, the conditions are not very well understood and, likewise, its hard to get a setup where this is consistently occurring and we can test different approaches.

I would really like to get your feedback on the errors we are seeing and the occurrence count.

Regards

[Edvin]

Hello,

It is still difficult to understand what causes this error when it is not possible to reproduce it regularly. I don't know what sort of devices this is. The error should occur after a disconnect, so it would still be useful to know the disconnect reason. If the devices are simply loosing radio contact (out of range, turned off) it would have a natural explanation. May that be the cause? A sniffer trace could be even better, (nRF Sniffer for Bluetooth Low Energy), as it could show some details if either of the devices are breaking the specification. 

Historically, it is not typical iOS devices to break the specification either, since they are one producer with full control of their HW, compared to Android. But I could be wrong. 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?

BR,

Edvin

[byves]

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?

[Edvin]

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

[byves]

its a return value from a function call on nRF

[Edvin]

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