My apologies. You were correct. I forgot to disable autoconn on the headset which is why i didn’t have to re-open. I’ve now restored both headset and source and made just the configuration change you suggested:

1) Borad1: transmitter. On the AGHFP. I changed PROFILES=ON 0 1 0 1 1 1 1

2) Board2: receiver. On the HFP (headset), I changed AUTOCONN=1 3

Source:

Headset:

I’m using two DISKIT’s for testing running the latest fw “V3.1.70”. the source is plugged into my PC streaming music and the headset is connected to wired earbuds. and i’m still able to reproduce the issue occasionally.. Your testing procedure looks to match mine.

I was able to develop a workaround for our product implementation so this issue is less of a concern now at this time..

my workaround is as follows:

1. source see’s ‘close_ok’ to indicate the headset lost power.

2. source see’s ‘open_ok’ to indicate it was reconnected.

3. source initiates call “call 12 incoming 121”

4. headset answer’s call ‘call 13 answer’

5. source ends call ‘call 12 end’

6. source re-calls ‘call 12 incoming 121’

7. headset answer’s call ‘call 13 answer’

On the second call, the audio seems to always be functional. my theory was that in the module internal state, a call needed to be ended before the state could be reset for the next call (or something along those lines).

In any case, this procedure, when controlled by a host micro happens actually surprisingly fast so it doesn’t add much to the initial connection time and as such is acceptable.