IDC777 module on custom PCN – no UART resplies

[mike_ts]

Hi,
I have an IDC777 BT module integrated on a custom host PCB that used to reply to full-duplex to all UART commands. For some unkown reason it no longer does, and also does not show up on the Communicator app “available devices” like other modules do (including the evaluation kit) ?!?
Essentially booting up the IDC777 displays the welcome message as :

IOT777 Copyright 2022
AudioAgent V3.0.46
Build: 223cea9a
Bluetooth address 245DFC020348
Ready
aptX Lossless: ON

Further interraction using the active CLI no longer yields any replies. Is it possible that during use the module has be partially bricked or rendered in a state that makes it no longer accessible. It’s almost like it’s ignoring any incomming ASCII characters, yet the outgoing characters are obiously sent given the welcome message at boot shows up on TeraTerm ?!?

Is there a hardware way to reset the module to defaul factory setting or something similar ? I can confirm doing a warm reset does not help getting back the full-duplex UART, but maybe there’s a factory reset that might work ?!?
As far as I know, flow control cannot be activated, and it is OFF by default so this could not have been activated even by mistake …

Do you have any suggestions as to why this might be happening and how to resolve it ? I have not seen this on the eval kit so far …

Thanks, Michael

[IOT747 Team]

Hi Mike,

It seems that you have faulty hardware. You would need to check all your hardware and compare to the DISKIT. The DISKIT and DISKIT schematics have to be used as a reference. the IDC777 cannot go into bricked mode. If the voltage applied is not stable and dips below 3V, it can end in a weird state. but power OFF and POwer ON again should get it back up and running.

You can RESTORE if you hold PIO3 at boot. See below from the manual. But it seems more likely this is from your hardware.

IOT747 Support

[mike_ts]

Hi,

The IDC777 ins installed on a cutom board with PIO_3 left floating by default as it was not being used for anything.
So if I ensure this pin is tied high, then power-up and boot the module, it will do the same as the RESETORE command ? Is this correct ?
So it won’t actually return to some factory version of the Firmware, but rather it will simply reset the module’s configuration to the factory default values, according to the current Firmware installed.

I may have to try this first… But I also suspect a possible hardware issue on the module itselft as the Rx displays the correct UART commands being sent from TeraTerm (checked with a DSO), but nothing comming out except for the Welcome message. Unfortunately I cannot interact further with the module…
If for some reason some flow control setting is out of wack maybe I can RESTORE it with PIO_3, so this might be worth trying first – thanks.

Regards, Michael

[mike_ts]

Ok, thanks it turns out there was a H/W issue on the board I was using. Replacing it solved the issue.

[mike_ts]

I have another quick question Ash, regarding some notifications I’m receiving, namely :
CALL_RINGING HFP 13
CALL_INCOMING HED HFP 7CB37BFB74E3 IDLE

What is the purpose of having both as it appears they both notify an incoming call that one has to act on ?
They appear to be in sequence.
Also I am not identifying the “HED” tag attached to the second notification ?!?! Is this some internal specific to the IDC777 firmware ? Is this something new as I was not seeing this in the previous tests on calls ?
Are these notifications allways sent with a call and should one expect them in a consistent sequence ?
We currently parse only the CALL_RINGING HFP 13 notification as this is ample info to store for active calls … perhaps it may be different if multi-calls need to be managed (not an immediate issue but may be later).
So if these are not too many questions perhaps you can shed some light on this please ?

So to summarise :

1. What is the purpose of having both notifications, as one seems enough ?
2. What is this “HED” tag ?
3. Are these notifications allways in the same expected sequence ?

Cheers, Michael

[IOT747 Team]

Hi Mike,

What firmware are you using?

IOT747 Support

[mike_ts]

It would be 3.1.70 or something similar.

[mike_ts]

Should this Tag “HED” not be part of, or have anything to do with the IDC777 firmware, it could be a possible glitch on my side that occurs (rarely) and that I would need to confirm. But if it is something that is part of the IDC777 firmware then it may be necessary to know … sorry for the trouble.
The other questions remain relevant though. So far I am seeing that CALL_RINGING always appears before CALL_INCOMING etc. So this is encouranging nevertheless….

[IOT747 Team]

Hi Mike,

CALL INCOMING and CALL_RINGING are 2 separate notifications from Bluetooth. We show them both if you need them. For HED, always compare with the IDC777-DISKIT if you think there is an issue. the IDC777-DISKIT always serves as a reference. 

Also, on the newer firmware versions, we display also the number and caller name if he get it. We also have PBAP and MAP. But if you have AA3170D, then it’s fine, you won;t have all these notifications.

IOT747 Support

[mike_ts]

Ok, that was a bug in the code. “HED” showed up as a phantom string.

Other thing I notice with the current code is that CALL_END is no longer sent. It appears that CALL_IDLE is now what is being notified after a SCO_CLOSE.

Is this corrent ?

Thanks, Mike

[mike_ts]

Hi there Ash,

How are you ?
I have a question for you regarding the capability of the IDC777 Bluetooth stack implementation with regards to the simultaneous use of the HFP and AGHFP profiles with phones and headsets.
Is this handled reliably on the IDC777 or should one assume it is better to not confuse the two profiles and to keep the separate during use with a phone or a headset ? I am ware of some BT stacks that will correctly handle such scenarios but am not sure if the IDC777 can as after trying, I do get some odd behaviour.

Namely with these settings : 
BT_CONFIG=1 1 0
PROFILES=ON 1 1 0 0 1 0 1
When I reboot the IDC777 the paired Shokz C102 headset connects automatically after a few seconds, like :
AudioAgent IDC777 V3.1.70
Build: 0400427b
Bluetooth address 245DFC020046
Ready
aptX Lossless: ON
PAIR_PENDING

OPEN_OK 12 AGHFP 2074CFB4E54B     <——– Shokz C102
ABS_VOL 12 13
STATUS
STATE CONNECTABLE[ON] DISCOVERABLE[IDLE] ADVERTISING[OFF] SCAN_UNI[OFF]
LINK 12 CONNECTED AGHFP 2074CFB4E54B IDLE
OK

When I manually connect the Android phone this is what happends straight after :

IOT747 Copyright 2022
AudioAgent IDC777 V3.1.70
Build: 0400427b
Bluetooth address 245DFC020046
Ready
aptX Lossless: ON
PAIR_PENDING
OPEN_OK 12 AGHFP 2074CFB4E54B
ABS_VOL 12 13
status
STATE CONNECTABLE[ON] DISCOVERABLE[IDLE] ADVERTISING[OFF] SCAN_UNI[OFF]
LINK 12 CONNECTED AGHFP 2074CFB4E54B IDLE
OK

And another attempted manual connection from the phone.
IOT747 Copyright 2022
AudioAgent IDC777 V3.1.70
Build: 0400427b
Bluetooth address 245DFC020046
Ready
aptX Lossless: ON
PAIR_PENDING
OPEN_OK 12 AGHFP 2074CFB4E54B    <—– Shokz C102 connects silently after a little delay …
ABS_VOL 12 13

It appears the IDC777 reboots, disconnects everything, then the C102 reconnects silently since BT_CONFIG=1 1 0.
The reboot was not initiated by my app, it happend when the manual connection to the phone was done on the phone.
This suggests to me some possible exception error on the IDC777 with this attempted manual connection from a phone, whilst a current connection was already in place with the Shokz C102 headset : OPEN_OK 12 AGHFP 2074CFB4E54B.

I would like to know if this is not something you recommend, or is/was not/never implemented yet etc. ?!?
perhaps this feature will be implemented at a later date ?

Regards, Michael

[IOT747 Team]

Hi Mike,

IDC777 can be HFP or AGHFP but not both at the same time. This is on the Roadmap but we don’t have a date for the release.

IOT747 Support

[mike_ts]

Ok, so that is good to know. We’ll need to ensure one or the other is selected by a button toggle or similar … thanx for the confirmation.

[mike_ts]

Hi, can you confirm, is it still necessary to do a RESET after a WRITE in the most recent firmware updates ?
Is the effect the same if after the WRITE, there is a H/W Reset instead of a software RESET ?
Thanks, Michael

[IOT747 Team]

Hello Mike,

1) For some configuration, you need to do a RESET for it to take place (For example AUDIO). For otehr, you don;t need to RESET. The manual tries to let you know whicch ones need RESET. But usually, it is better to RESET for safety.

2) Once you do a WRITE, it writes the new configuration on the Flash. So you can Reset in software or Hardware and it’ll work.

IOT747 Support

[mike_ts]

Hi, ok, that’s good, since we have a special case where I need to change the CONNECTABLE state to OFF before we do a reboot or a switch off of the PCB. So we can avoid doing a software reset and then another hardware reset in a row… Just checking, but from what I can tell it works as intended wuth the hardware reset … thanx

[Author]

Posts