Possible NCS controller bug for peripheral if CONFIG_BT_REMOTE_VERSION=y

[variant]

The following issue is for NCS version 1.4.0 and 1.4.1 for an nRF52840 DK target.

When CONFIG_BT_AUTO_PHY_UPDATE=y for both a peripheral and central, I see in Wireshark a LL_PHY_REQ from both sides, as expected.  Here’s an example.

As soon as I simply add CONFIG_BT_REMOTE_VERSION=y to the peripheral’s prj.conf, the peripheral no longer sends a LL_PHY_REQ, as shown below.

• Even several seconds (>5 s) after the connection, I don’t see in Wireshark an LL_PHY_REQ from the peripheral.

You should be able to reproduce this issue with the peripheral_uart and central_uart projects by just adding this line to the peripheral uart’s prj.conf:  CONFIG_BT_REMOTE_VERSION=y.

The missing LL_PHY_REQ from the peripheral has ramifications such as subsequent user-requested connection parameter updates don’t get sent when using bt_conn_le_param_update().

• The missing le_phy_update_complete() due to the suspected bug prevents resumption of calls to conn.c/conn_auto_initiate() to continue auto-initiated procedures. 
• That means slave_update_conn_param() never gets called in conn_auto_initiate(), which prevents the call to k_delayed_work_submit(&conn->update_work, CONN_UPDATE_TIMEOUT),
• The missing "delayed_work" means conn_update_timeout() never runs, preventing auto connection parameter updates and subsequent user-initiated updates.

I haven't verified if this problem occurs with the Zephyr stack instead of the Nordic stack.

[Carl Richard]

Hi!

Great. Looking forward to your response! And yes I do agree. This is very relevant information for other customers aswell.

Best regards,
Carl Richard

[variant]

Hi Carl!

Thanks for all that great info above.

I can confirm that I am using the Softdevice controller, not the Zephyr BLE controller, as my build's .config file has:

# CONFIG_BT_LL_SW_SPLIT is not set

CONFIG_SOFTDEVICE_CONTROLLER_S140=y 

Is that good enough evidence?  

As far as providing complete Wireshark logs, they can be easily obtained with the prj.conf change to peripheral_uart that I mentioned earlier.

In my actual project where I discovered this issue, I had CONFIG_BT_USER_PHY_UPDATE=y as well as CONFIG_BT_AUTO_PHY_UPDATE=y for my peripheral device.  

• The bug prevented the peripheral from transmitting the AUTO case for LL_PHY_REQ, so the USER case later on was also not able to be transmitted (nor could other types of LL requests get transmitted). 
• Of course, when CONFIG_BT_REMOTE_VERSION=n, the peripheral transmitted both LL_PHY_REQs (auto and user). 
  • Interestingly, in the latter case (REMOTE_VERSION=n), the master responded with LL_UNKNOWN_RSP since it only supported PHY 1M, even though it was BLE v4.2 compliant. 

To keep the issue description simple, I pointed to the peripheral_uart as a way to replicate it.  But in my project, it got more complicated since I had both AUTO and USER updates for PHY and DATA_LEN. 

Question:  If the issue is due to DRGN-11963, where in the NCS/Zephyr code can I check for the “Controller Busy (0x3a)” error code?  That would be very useful for me to know where those SoftDevice error codes get returned from the SD black box to the visible SW. 

Thanks,

Variant

 

[Carl Richard]

Hi again, Variant!

No problem. The evidence is absolutely good enough! Though, I figured out that your initial post gave me the answer aswell as most NCS BLE samples (including peripheral_uart) are configured to use the SD controller. Thanks for the clarification anyway! Your thourough description of the issue is appriciated aswell!

As for your question, I got from the developers that the HCI error codes aren't given to the application (you can see how they are handled in the hci.c and hci_core.c). However, the behavior described hin this case is a regression and it will be adressed. Hence, handling it should not be necessary. 

Best regards,
Carl Richard