Zephyr BLE: bt_le_scan_start Fails with Error -5 (-EIO)

[wliao]

I was running BLE tests between two nrf52dk boards and from time to time I saw the error message as below:

W: opcode 0x2005 status 0x0c

And my debug message showed as: BLE_GAP_StartScan error (err = -5), which printed out when the function bt_le_scan_start returned a non-zero error.

Could it be a BLE stack issue?

Thanks for the support!

[AHaug]

Hi,

Could you elaborate some ore about what you've done?

1. Have you traced where in the callstack this error is triggered? It could lie deeper than bt_le_scan_start()
2. Are you basing your tests on any samples existing in nRF Connect SDK?
3. What SDK are you using?
4. Are you aiming for anything specific with your tests? If so are there any information there that might be relevant, for instance if you've written custom code the fault may be caused by not using the API correct

Could it be a BLE stack issue?

From https://docs.zephyrproject.org/apidoc/latest/group__bt__gap.html#gac5e19c26b53a08dadb8efa7ecc692ad6 you can see that a negative (POSIX) error number is returned in case of stack internal error. 

Kind regards,
Andreas

[wliao]

1. I didn't record the callstack last time but I will if I have the same issue next time.

2. The test was based on our custom code.

3. The SDK is v2.4.0 of nrf Connect SDK

4. As to the test itself we just ran the cycle of connecting, exchanging some data, disconnecting and reconnecting to make sure the communication robust.

5. I also noticed there was a similar complain about this error last year, here is the link:

https://github.com/zephyrproject-rtos/zephyr/issues/50438

Thanks!

[AHaug]

Thank you for clarifying

wliao said:

1. I didn't record the callstack last time but I will if I have the same issue next time.

Let me know if you find something there

wliao said:

5. I also noticed there was a similar complain about this error last year, here is the link:

Do you mean "Similar", or "Identical and reproduceable on your firmware"? This report were posted in 2022 where they used NCS v2.1.0, meaning that this might have been fixed in later versions.

I will check if I'm able to reproduce the steps in the bug report in v2.4.0 with two 52840dks but it might be a while before I have time to do so. In the meanwhile let me know if you're able to reproduce it on your firmware.

Kind regards,
Andreas