Built nRF5340 Audio sample application through VSCode extension, radio nonfunctional.

[bstewart-cae]

I'm experimenting with the BIS and CIS versions of both the gateway and earbud and am having a hard time getting back to a known working state. I am using Ubuntu 22.04 and on Connect SDK v2.4.1.

I created a new application using the sample app as starting point by using the wizard. this app lives in my local repo.

Building the application directly in the ncs/ directory works fine using the buildprog script. I copied the lib->bin->bt_II folder over into my repo to try to recreate this functionality, as the buildprog.py needs those binaries for the net core. Building with the script in my repo seems to work and I can load binaries onto both the application and network cores. So far, so good. 

Next, I added configuration files for the 4 combinations of gateway, earbud, and BIS/CIS. To these config files I added the corresponding CONFIG_AUDIO_DEV and enabled/disabled the transport depending on the prj_*.conf file I'm using:

Next, I created a build configuration for each one of these config files. I did a pristine build and flashed them onto the corresponding earbud and gateway dev kits. The kits fire up with no issues and claim they begin scanning and advertising, and my laptop can see the audio gateway and play audio.

However, according to the sniffer on my phone (pixel 6, latest update does support BLE), neither devkit is actually transmitting anything and it cannot see any advertising going on at all. The kits do not find each other and just sit in pairing mode. This happens regardless of combination of CIS/BIS. Any ideas?

I also was sure to flash the precompiled ble5-ctr-rpmsg_3349.hex file onto the network core in addition to the application.

[bstewart-cae]

Edit:

The only other difference is the CONFIG_AUDIO_DFU option, and for whatever reason enabling this to either 1 or 2 got the earbud to connect. Best as I can tell, doing this forces an empty application onto the network core and calls a setting update on power up. not sure why this is related, but it's something. Any ideas why enabling remote firmware update would make this work?

[ovrebekk]

Hi Ben

Building and flashing through VSCode is not supported unfortunately, as mentioned here.

We are planning to support this later on, but we don't yet have a schedule for this. 

Best regards
Torbjørn 

[bstewart-cae]

Hey Torbjorn,

Thank you for getting back to me. Just so I know what is happening, this doesn't work because the network core is getting overwritten with an empty app, is that correct?

[ovrebekk]

Hi Ben

The LE Audio project is a bit special in that it uses a dedicated Bluetooth controller provided as a precompiled hex file. 

The netcore needs to be flashed with this hex file in order for the application to work. 

Not only that, but when using DFU the Bluetooth controller needs to be offset in flash to make room for the bootloader, and the hex file needs to be signed, and all of this is handled by the build script. 

Finally the script makes it easier to manage the flashing of multiple boards when you need to flash a gateway and one or more headsets at once, but this is just a convenience feature. 

Best regards
Torbjørn