Hi there

I am using a HL7800 with FW 3.5.0 on Linux and experimenting with its USB interface since I would prefer it over UART. I am not able to get anything out of its ttyACM interface and trying to debug the issue. What i noticed is that I have “strange” USB ID’s:

When KUSBCOMP was at 0, I had:
Bus 002 Device 002: ID 216f:0051

Since KUSBCOMP is set to 1, I have:
Bus 002 Device 003: ID 216f:0060

From the AirPrime_HL78xx_AT_Commands_Interface_Guide_Rev9_3 I would have expected to only see ttyACM interface(s) with KUSBCOMP=1. Also the above document states that the PID should be 0xC001 which does not apply to either case. Any ideas what might be going on here?


It has an issue with +KUSBCOMP command in FW 3.5.0 HL7800.
I tried it with FW I can type AT command on ttyACM interface and USB PID is correct in FW HL7800.

You can get this FW as below:,-d-,7,-d-,2,-d-,3/#sthash.kzfQW4ka.dpbs

Hi Donald

Thank you for the information.
Is there any way to get the HL7800 with FW 3.5.0 and KUSBCOMP=1 back into KUSBCOMP=0 since it seems that it is now neither responsive over USB nor UART?

Hi tristanramseyer,

To back into KUSBCOMP=0 with FW 3.5.0 HL7800, You need to attach USB cable to UART0_USB module with these steps below:

  1. Open UART0_USB port with “None flow control” in software tool
  2. at at+kusbcomp=0
  3. at at+cfun=1,1

Please find the screenshot for your reference.
UART0_USB_Linux UART0_USB_module !

Hi Donald

I have the HL7800 actually integrated into an embeeded system and assume that you are using some kind of evaluation board.
The design of my system was initially made for a HL8548 and since the UART0 RX/TX pads C55/C56 of the HL7800 are not present (“NC”) on the HL8548, I have no simple possibility of accessing the UART0.
If there is no other possibility to reset the HL7800, I will mark the entire board of my system as defect and use a new one (luckily I have 10 of them).

I have updated an other, new HL7800 to FW prior to setting KUSBCOMP=1. After a few seconds of bootup I saw VID:PID 1199:c001. I was also able to use the ttyACM0 over wvdial just as it was the case with the HL8548. (Now the next step is to ensure that in our production modules with FW or newer with ideally KUSBCOMP=1 are used.)