Need help with FSC-BT631D - HFP profile

KnutKaald

Hello, we are on a project using the FSC-BT631D (+VER=BT631D,V3.1.2,20251201) with classic Bluetooth and HFP profile activated for a 'special' headset use.
We are currently running small test batches where we have used bluetooth playback features only.
When starting to test the HFP, we find that the module simply gets stuck as soon as the HFP profile is activated.
When using the default profile AT+PROFILE=9387 the following is the output from the BT631D when calling the device and without doing any attempt to answer the phone from the BT631D (which is connected to an iphone via bt - and the BT631D has the factory configuration) - the module simply freezes:

+HFPSTAT=5
+HFPSTAT=5,+4712345678,Nameofcaller
+HFPAUDIO=0
+HFPAUDIO=1
+HFPSR=16000

From now on the BT631D is stuck. It does not respond to any serial input, and must be hw reset.

If disabling the HFP bit in the profile (resetting the BT631D, restore factory settings and then give the command AT+PROFILE=9379 (HFP disabled), the module can play music, but it does not show incoming calls which I assume is perfectly correct.
It seems like the HFP profile is not working here. Any advice on how to get through this fairly serious issue ?
Knut

FAE_Gavin

KnutKaald Hello, regarding the FSC‑BT631D HFP freezing issue you reported (the module becomes unresponsive on UART), to help our R&D team quickly reproduce and diagnose the problem, we would appreciate it if you could provide the following details:

Test Environment & Hardware Setup
- Are you using an official Feasycom development board, or did you wire the module yourself?
- Please verify that the UART connection is stable, with no loose wiring, voltage level mismatch, or signal interference.
Complete AT Command Log
- Save the full AT command sequence and all module responses from power‑up until the issue occurs using a serial terminal tool.
- After the module hangs, try sending other AT commands (e.g., AT or AT+VER) and record whether you receive any response.
Mobile Phone Details
- Provide the exact model and iOS version of the iPhone used for testing.
Functionality Verification When the Issue Occurs
- After the module hangs (UART unresponsive), test whether the Bluetooth call and audio are still functioning normally (e.g., does answering/hanging up still work? Can the other party hear you? Is the microphone active?).
- This helps determine if only the UART event reporting is blocked, while the Bluetooth stack and data links remain operational.

Thank you for your cooperation!

KnutKaald

FAE_Gavin
Hello Gavin - thanks for replying even if it is in the middle of your CNY holiday!
I believe we have found the problem: the BT631D in our system is not connected to the TLV3204 codec via I2C.

In our system, we are in fact using a TLV3204 codec, but it is controlled by our SAMD microcontroller.
On the BT631D , the I2C pins are left floating - and this works very well for everything apart from when using the HFP profiles.
For a unit like the BT631D, requiring a TLV3204 codec is not really a good solution, cause many applications (or even most) will use a different, more affordable and simpler codec than the TLV3204.
And I would bet that close to 100% or the applications using a BT631D modem would like to control the codec themselves and not relying on the BT631 controlling it via AT-commands.

As soon as we connect the TLV3204 directly to the BT631, it works like a breeze. Unfortunately, we can not do that in our system, cause the BT631 is overwriting our configuration when it is controlling the TLV3204 codec.

So to the questions:

Do you have a software version for the BT631D which is not sending I2C data to the codec (or ignoring not getting a reply from the codec)?
If not; can you compile a version where the BT63 does not expect I2C data back from the codec ?

If none of these options are available, we are deep in something wet and dark.

Happy CNY - drink lots of beer!
Knut

FAE_Gavin

KnutKaald Thanks you.We are on the New Year holiday from February 14th to February 23rd.
We’ll reach out to you right away when we get back to work!

FAE_Gavin

KnutKaald After our R&D engineers finished checking the issue, they have provided a new firmware for testing. This firmware supports normal HFP calls without using the 3204.

I have sent the new firmware version to you via email. Please check your mailbox.

KnutKaald

Hello Gavin, thanks for your reply!
Have sent you a message to your email.
Knut

KnutKaald

Hello again Gavin, success!
We have succesfully updated the BT631D from BT631D,V3.1.2,20251201 to BT631D,V3.1.3,20251201 (from V3.1.2 to V3.1.3 both versions same date 🙂 )

When first trying the OTA update, we used the nRF Connect (from Nordic Semi here in Norway of course) on an iPhone 8. Here we got a hang issue when trying to do the OTA.

We changed to an iPhone SE - downloaded the nRF Connect + fw file.
On the iPhone SE the update went as a warm wind through the Norwegian mountains. No issues at all.

I found some reports on the Nordic web site that the iPhone 8 was a problem. I will update the nRF on my I8 as well just to confirm that this was the issue - and not that I had an older version of nRF Connect on my phone.

So the update issue is solved.
**
A quick test on V3.1.3 shows that it continues to run after a call. Have not tested the audio on the phone connection yet; as you might know - the 3204 is fairly complicated and you need to have your tongue in the right mouth when doing the config here.
Will give you a full report though!

Thanks a lot Gavin for your tremendous support! Even mid CNY!
Report is coming!
Knut

FAE_Gavin

KnutKaald Hi Knut,

Thank you for the great news and the detailed update! We're glad to hear that the OTA update to V3.1.3 went smoothly and that the module now behaves as expected after a call.

Looking forward to your full report when you're ready.

KnutKaald

Hello Gavin, we finally got the time to do a full test of V3.1.3 on the BT631D
We find that 'everything' works - apart from voice out from the BT631 when being in a phone conversation.
From our system using the BT631, we can hear the calling part, but the calling part can not hear us.

We have verified that I2S data is going OUT from the BT631 into the TLV3204 codec (otherwise we could not hear the calling part 🙂), and that I2s data is going out from codec into BT631 (pin 16 - P0.13/I2S_DIN ).

We have verified that the i2s data out from the codec is correct (physical loopback of the i2s_out signal into i2s_in on the codec for testing).
When initiating this test we get the serial responce from the BT631:
+HFPAUDIO=1
+HFPSTAT=6
+HFPSTAT=6,000000
+HFPSR=16000

When checking the mic with the command AT+MICMUTE, we get the responce:
+MICMUTED=1
I assume this is a misspelling in the format cause the response should be +MICMUTE=1, but the '1' parameter indicates that the mic is muted.
Giving the command AT+MICMUTE=0 gives the response +MICMUTED=0, but when checking the mute situation again with the command AT+MICMUTE, the BT631 is responding with +MICMUTED=1 - meaning the mic is muted.

Any idea what is wrong ? Can it be a problem with global heating ???🙂

KnutKaald

Hello Gavin, someone in the team (not me) got this bright idea to do an electrical loop test on the BT631: simply connecting the I2S output to the I2S input.
This simple test gave us the sidetone on the device connecting to the BT.
And it tells us, that we have screwed up in the configuration of the codec (the TLV3204 is not the easiest to configure).

Will fix this issue on our side - and get back to you with good news I hope!
Happy Easter!

FAE_Gavin

KnutKaald Hi Knut,

Thanks for the update and the clever loopback test — great debugging! Glad to hear the BT631D is fine and the issue is on the codec side. You're definitely on the right track.

No need for further assistance from us at this point, but feel free to reach out if any BT631D-related questions come up.