BLE Error when calling disconnect inside callback for connected

RE: BLE Error when calling disconnect inside callback for connected

douglas.malnati — Fri, 09 Sep 2022 21:38:32 GMT

I understand. Thank you.

The work queue introduces the issues as well.

Regarding nRF5 SDK, is that not deprecated in favor of NCS (Nordic Connect SDK)?

RE: BLE Error when calling disconnect inside callback for connected

Edvin — Mon, 05 Sep 2022 09:13:46 GMT

For follow up questions, please consider creating a new ticket. I will be working on another project in the coming month, so I will not monitor my queue until October. Please feel free to link to this one for background information.

So in Zephyr, there are a lot of callback handlers in the different modules. One for your main application, one for the flash management (in case you are storing bonding data, and so on), and there are several callback handlers within the Bluetooth stack. When this event occurs, these event handlers are all called, and the order in which they are called is a random order. Therefore errors like this can happen when all the handlers have not yet had time to execute.

Therefore, my suggestion to you is that you wait until all of these handlers have had the chance to run. The way that I suggested was to use a timer, but if you are not too keen on that, then I suggest you look into the k_work handler. The meaning of this (and the handler) is to handle the disconnect job at a different priority level than the Bluetooth callback itself. So that we know that they are handled in the correct order. Please see the section "Submitting a work item" in the NCS documentation.

I am not sure whether or not you are familiar with the nRF5 SDK, which is a more "bare metal" SDK. In there, you will not see these kinds of issues, because the SoftDevice would run a bigger part of the Bluetooth Stack, which would handle these events completely before letting the application know that they had happened. However, the complexity of an RTOS means you also need to take these scenarios into consideration. After all, it is still a single core chip running a complex RTOS with many threads running "concurrently", and interrupt priorities still need to be taken into consideration.

Best regards,

Edvin

RE: BLE Error when calling disconnect inside callback for connected

douglas.malnati — Fri, 02 Sep 2022 01:38:07 GMT

Nothing obviously not working, but that's not a confirmation, It's hard for me to tell if there are any bugs because I'm in the initial development phases and haven't really put the system to hard work yet, or prolonged and rigorous exercise.

My primary concern is corruption of state within the zephyr code which will manifest itself much later in time (and will be very difficult to diagnose).

[quote userid="109356" url="~/f/nordic-q-a/91486/ble-error-when-calling-disconnect-inside-callback-for-connected/384385"]it is totally allowed to initiate a disconnection immediately after the connection has been created[/quote]

Not clear your specific meaning here. Do you mean specifically it is ok to call the disconnect function while still within the "connected" callback? If you do mean that, what makes you sure that's correct? I have not seen any statements or documentation so far that have asserted that.

[quote userid="26071" url="~/f/nordic-q-a/91486/ble-error-when-calling-disconnect-inside-callback-for-connected/384138"]Remember that there are many handlers that subscribe to the BT events, such as the connected event[/quote]

My thought is around this statement, that perhaps other subsystems within zephyr haven't yet received the connected callback (if there are any) before I have, and there's some kind of race condition. Or the order in which the event is distributed is non-deterministic, or something. But because it's an intermittent problem, it tells me that the same code path isn't being executed each time for equal events, and that's within the zephyr functionality (and wrong).

Thanks.

RE: BLE Error when calling disconnect inside callback for connected

Emil Lenngren — Thu, 01 Sep 2022 22:18:38 GMT

If we disregard what errors/warnings you see in the log, is something buggy or not working as expected?

If everything appears to work as expected, Nordic should consider removing these warnings/errors when the state is "BT_CONN_DISCONNECTING" as it is totally allowed to initiate a disconnection immediately after the connection has been created.

RE: BLE Error when calling disconnect inside callback for connected

douglas.malnati — Thu, 01 Sep 2022 18:23:46 GMT

Thank you for your response, however I feel the API needs to be written and clarified.

I'm not seeing concrete statements about what I can/cannot do, and that is the function of an API, and it should be documented. I am not finding documentation describing what I can/cannot do either and I asked to be directed to any which didn't happen either.

In BLE, as a peripheral, you are supposed to allow anyone to connect

As a peripheral, I did let anyone connect, and subsequently chose to disconnect them. There is a disconnect function I used to do that, so clearly this is a concept that is supported.

I am just saying that the error says that you are not connected, and it is triggered from the action of trying to disconnect before the connection event has propagated though the operating system

I understand you are saying that. But what you aren't saying is when it is supported for me to disconnect, and you aren't pointing me to documentation that tells me. I've been suggested to "try" waiting, as though there isn't a definitive supported answer to that question, which is exactly the point I'm struggling with here.

The API as I'm using it is already inconsistent, there is an intermittent issue where sometimes there is a warning, other times not, for the exact same code path execution. How should I know that when I "try" waiting I'm simply not seeing another instance of an intermittent issue?

The answer to all of these things is having an API which conclusively explains the right way to operate the system.

Please think if there is something specific you can say about how to use this API correctly.

Also please pass along a report that the API is not clear in this (and so many other) places.

Thank you.

RE: BLE Error when calling disconnect inside callback for connected

Edvin — Thu, 01 Sep 2022 12:51:38 GMT

Hello,

I suggest that you look into the "Using a Timer Expiry function" section in the NCS documentation.

[quote user="douglas.malnati"] That's the zephyr API's job to present an interface which I can reliably work with to build an application.[/quote]

In BLE, as a peripheral, you are supposed to allow anyone to connect. Whether you take action on the events generated from the connected device is up to you. There are mechanisms (bonding and so on) to prevent malicious devices from doing the wrong things.

[quote user="douglas.malnati"]Regarding ignoring the problem, should I ship a commercial product with outright errors being produced by the underlying library?[/quote]

I am just saying that the error says that you are not connected, and it is triggered from the action of trying to disconnect before the connection event has propagated though the operating system (Zephyr).

Sorry for the short answer, but I need to leave the office, and will be out for the weekend.

Best regards,

Edvin

RE: BLE Error when calling disconnect inside callback for connected

douglas.malnati — Wed, 31 Aug 2022 14:24:45 GMT

Hi,

1 - I already do call bt_conn_ref(conn).

3 - conn->state == BT_CONN_DISCONNECTING. When the connected callback fired, the state was BT_CONN_CONNECTED and err=0.

The zephyr disconnect callback does fire after I bt_conn_disconnect within the connect callback.

Regarding points 2 and 4 - This sounds like "work around or ignore" the problem. My specific question on this case is what the right way to use the API is. I cannot find documentation that explains when I'm allowed to call which functions under which scenarios. Can you please direct me?

Adding a timer leads to many many negative issues, like my code now having to track that a connected conn "isn't really supposed to be connected so ignore any callbacks from it." That's the zephyr API's job to present an interface which I can reliably work with to build an application.

Regarding ignoring the problem, should I ship a commercial product with outright errors being produced by the underlying library? Is there library state corruption occurring? What specifically is the consequence of this error such that I can safely ignore it? My concern is that non-deterministic errors are being produced when my code executes in exactly the same sequence, and it is highly unsettling.

Thanks.

RE: BLE Error when calling disconnect inside callback for connected

Edvin — Wed, 31 Aug 2022 12:28:05 GMT

Hello,

Without digging too deep into the call stack, I guess that this is just caused by the connection not being set in the correct instance before you call bt_conn_disconnect().

Remember that there are many handlers that subscribe to the BT events, such as the connected event. If then, you disconnect from within the connected event, and this triggers some internal event, which checks the connection state before that handler ever got the connected event, you will get these scenarios.

A couple of suggestions that you can check:

1: Make sure to call

current_conn = bt_conn_ref(conn);

before you disconnect. This will tell the bluetooth stack that it is connected, and update some internal connection handle. I am not sure whether this is the one that it is complaining about or not.

2: Try to add a delay from the connected event. Add a delay of e.g. 50ms by starting a timer in the connected event, and then disconnect in the timeout handler.

3: Try to set a breakpoint in bt_conn_send_cb() on line 381 in conn.c (the one printing "not connected!"), and look at the callstack. See if you can see what the conn pointer is, and what the conn->state is.

4: Try to ignore this error message. You are trying to disconnect either way. Does it trigger the disconnected event? Are you in a connection at a later point in time, or does it start advertising again?

Best regards,

Edvin