nRF Connect SDK 2.4.0 Bluetooth Failures

[brushlow]

Hello,

I am in the process of migrating two projects (based on Central UART and Peripheral UART) to nRF Connect SDK v2.4.0 from v2.0.0. I did an interim migration to v2.3.0, which is now up and working fine with several changes. However, the last step of moving from v2.3.0 to v2.4.0 is not working; my nRF5340s (both Central and Peripheral) no longer connect. The Central device seems to fail at the MTU exchange step:

MTU exchange failed (err 14)

I did notice that the following Kconfig symbols (which were used on the Peripheral side) look to be replaced :

CONFIG_MCUMGR_SMP_BT                  > CONFIG_MCUMGR_TRANSPORT_BT
CONFIG_MCUMGR_SMP_BT_AUTHEN > CONFIG_MCUMGR_TRANSPORT_BT_AUTHEN
CONFIG_MCUMGR_SMP_SHELL           > CONFIG_MCUMGR_TRANSPORT_SHELL

These were replaced with what I assume are the new symbols, but I am wondering if there is anything else with SMP that has changed in v2.4.0? Or anything else related to BLE pairing that would suddenly cause MTU exchange to fail?

Thanks

[brushlow]

Adding a bit more detail:

Prior to the MTU exchange failure, bt_conn_set_security() fails with error code -12. This seems to be ENOMEM, not enough core.

More importantly, the Peripheral is using the Zephyr BLE stack. When I change that to use SoftDevice, things work fine. So I would assume this is something with the latest Zephyr BLE stack.

Thanks again

[AHaug]

Hi,

Based on your latest reply it sounds like there could be something with the Zephyr controller, but it could be something else

1. Could you state if your central uses the SoftDevice or Zephyr controller?
2. There were a change in 2.1.0 which led to stack size issues when migrating up in versions, but that issue were relatively easy fixed by increasing said stack. If you managed to port it up to 2.3 this issue should not be the case for you. In addition if you had issues with the stack size, you shouldn't have gotten as far as the MTU exchange in the procedure.
3. Could you check if you are able to migrate the peripheral and central UART samples from the samples in v2.3.0 to v2.4.0 (i.e take the source code from the v2.3.0 samples and attempt to migrate and build to v2.4.0)? If this is possible, then that narrows down the error you're observing to be elsewhere in your application than in the "base peripheral/central application"

Kind regards,
Andreas