Closed matt-wood-ct closed 1 week ago
matt-wood-ct
commented
3 weeks ago @henrikbrixandersen @PavelVPV Is there anyway we can get this looked at fairly quickly as I have a rather large hardware design decision hanging on this capability, sorry to chase
aescolar
commented
3 weeks ago CC @jhedberg
cvinayak
commented
3 weeks ago @matt-wood-ct Please add the below to prj.conf of your hci_spi sample, so that it periodically logs the thread program stack usage (also, acts as a heart beat assuring the Controller is alive).
CONFIG_THREAD_ANALYZER=y
CONFIG_THREAD_ANALYZER_AUTO=y
CONFIG_THREAD_ANALYZER_AUTO_INTERVAL=5
CONFIG_THREAD_NAME=yDo provide the log here...
matt-wood-ct
commented
3 weeks ago @matt-wood-ct Please add the below to
prj.confof your hci_spi sample, so that it periodically logs the thread program stack usage (also, acts as a heart beat assuring the Controller is alive).CONFIG_THREAD_ANALYZER=y CONFIG_THREAD_ANALYZER_AUTO=y CONFIG_THREAD_ANALYZER_AUTO_INTERVAL=5 CONFIG_THREAD_NAME=yDo provide the log here...
@cvinayak
Added that config to both side, just in case, can confirm both sides are running See logs below:
matt-wood-ct
commented
3 weeks ago To make mesh on HCI work do I need CONFIG_BT_HCI_MESH_EXT enabled?
I just tried to turn it on but it has a dependency I can't resolve, it wants CONFIG_BT_LL_SW_SPLIT=n but that can never be the case because if you are a Bluetooth controller you are required to have a BT_LL_CHOICE and BT_LL_SW_SPLIT is the only choice...
Ok more investigation, I forced CONFIG_BT_HCI_MESH_EXT on by changing the dependencies and discovered that that then tries to include a file (ll_sw/ll_mesh.h) which doesn't even exist any more, so I that that config is likely left over from an older implementation (circa 2018/19)
matt-wood-ct
commented
3 weeks ago FYI I did also try using nordics hci_lpuart sample in conjunction with the same beacon and mesh samples configured for H4 HCI rather then SPI on the NRF52832 ICs and found the same result, beacon works, mesh does not appear to work.
Note, I don't have logs for this since the NRF52832 only has one UART so I had to use that for the interchip comms. In principle you could get RTT up and running but I was just trying to do a quick and dirty test so I used minimal overlays and confs.
PavelVPV
commented
3 weeks ago Hi @matt-wood-ct, I'm on a leave atm and can't try the sample at my desk, but the first thing comes up to my mind when trying to build mesh separately of controller is misconfiguration of host and controller. Though IIRC you should have had an error when host and controller are misconfigured, it is worth comparing bluetooth configuration (CONFIGBT* Kconfigs from .config file in build folder) of single image build (when host and controller are built together) and multi image build (the one you have).
matt-wood-ct
commented
3 weeks ago Hi @PavelVPV, thank you for your time, I have extracted those configs and I am going through the differences now, will probably take me a few hours to go through (I'm having a busy day) so in the mean time here are the 3 files.
jori-nordic
commented
1 week ago Controller is missing CONFIG_BT_EXT_ADV=y.
Reproduced the issue on my (and a colleague's) desk. Added config, and it works as you can see from the video. We're able to provision and have two DKs control each other's LED.
it-werks.webm
Here's the exact branch I used: https://github.com/jori-nordic/zephyr/commit/bfb3e3090dc534ec7d3797eb6667685e8de2ff38
matt-wood-ct
commented
1 week ago Controller is missing
CONFIG_BT_EXT_ADV=y. Reproduced the issue on my (and a colleague's) desk. Added config, and it works as you can see from the video. We're able to provision and have two DKs control each other's LED. it-werks.webm
@jori-nordic Thank you so much for this I will retest soon to make sure but it looks like you've cracked it 😄
This is a really important proving exercise for the project I am working on
jori-nordic
commented
1 week ago No problem :)
Feel free to review and +1 the doc change if the instructions work for you: https://github.com/zephyrproject-rtos/zephyr/pull/76161
Describe the bug So I am attempting to validate using a NRF52832 SOC as an external BLE controller for use in a BLE Mesh application and I am struggling to get BLE Mesh to work using a BLE controller connected via SPI.
* P0.21 functions as the HW RST on these dev kits
To Reproduce Using_SPI_HCI_for_mesh_and_beacon_samples.patch
hci_spiandmeshsamples (see attached patch file)Expected behavior Mesh sample to run as it does with a combined host and controller build on a single dev kit
Impact
Showstopper for using mesh on an external BLE controller
Logs and console output Host:
Controller (log level increased as it ordinarily would say nothing):
Although the logs look like it is doing something, there is nothing futher after those messages and I am unable to see any mesh advertisements using the NRF connect app or the NRF mesh app.
Environment (please complete the following information):
Additional context I did validate my device tree and configurations using a simple BLE beacon sample, this operated without fault and proved the connections are correct.