I'm running the latest nrfF5340_audio (2.3.0-rc1) application for both headset and gateway using two nRF5340 Audio DKs. The only modifications to the installed code are in proj.conf:


I'm running the latest nrfF5340_audio (2.3.0-rc1) application for both headset and gateway using two nRF5340 Audio DKs. The only modifications to the installed code are in proj.conf:


Hi
When the issue occurs will a power cycle of all the boards not be enough to fix it?
Do you see any warnings or errors when flashing the boards that could explain the issues you are seeing?
How do you flash the boards, are you using the provided scripts, or doing it in some other way?
One thing you can try is to update to v2.3.0-rc2, which includes a newer version of the LE Audio controller (3330 vs 3322). This version of the controller has various fixes includes, some of which are related to connection issues, but my gut feeling is telling me that your issue is not really related to the controller.
Best regards
Torbjørn
This morning I did a "nrfjprog --recover" operation on both coprocessors and reprogrammed both DKs (using provided scripts) with the original prj.conf and they connected again. Playing around further shows that it is the " CONFIG_AUDIO_SOURCE_I2S=y" on the gateway that is the problem. I'll try v2.3.0-rc2 but I'm guessing something in audio_cis_gateway.c is the problem.
Forget everything I just said! The problem I am having is due to the fact that a different random address is being generated with each build and I missed the "all bonded slots filled, will not accept new devices" message that shows up when devices are reconnected or disconnected. I need to learn how to set a static random address that persists through builds and also need to learn how to empty or clear the bonded slots.
And finally, v2.3.0-rc2 isn't showing up in device manager yet, even though I updated to the latest.
Thanks for your help!
Hi
Thanks for the update. I must admit I didn't consider the possibility of bonding being the issue here, but bonding will definitely fail if one device is bonded while the other is not.
If you keep BTN5 pressed during boot this will erase any existing bonding data in the device. In the case that you only program one of the boards it should be sufficient to reboot the other device with BTN5 pressed, in order for both of them to start with a clear slate.
By now the full v2.3.0 release should be available through the Toolchain Manager, in case you want to try the latest version.
Best regards
Torbjørn