We have a custom board design which has a connection to HL7688.
We were able to use the HL7688 through USB to our main board and perform AT operations.
But when I upgraded my firmware from A.2.10.4 version to A.2.15.1, our main board is not detecting the HL7688 as CDC-ACM device instead it is still detecting it as Flash device( idVendor=8087).
But when I use the same module in dev kit everything works fine.
Can someone help me figure out what could be the issue? What change in firmware is causing us not to detect the HL7688 any more?
Hi Harishk07,
What is your OS?
If in Windows, could you install the USB drver again? You can get the driver here:
https://source.sierrawireless.com/resources/airprime/software/hl854x-usb-drivers/
If you test in Linux, could you provide your dmesg log?
Hello Klin2
I am working with Linux and as well as trying with windows 10
The following are the logs from linux dmseg.
[1438128.119727] usb 1-6: New USB device found, idVendor=8087, idProduct=0716
[1438128.119729] usb 1-6: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[1438128.125256] usb_serial_simple 1-6:1.0: flashloader converter detected
[1438128.125330] usb 1-6: flashloader converter now attached to ttyUSB0.
This only happens when I use our custom board to to connect the HL7688 to PC. If I use the HL dev kit to connect, I have no problems.
But our custom board is working fine with A2.10.4 version of the software.
Thanks
Harish
Hi Harishk07,
In the customer board, Do you ever use some GPIO for the shutdown control?
If you upgrade back to A.2.10.4, then no issue issue with the customer board?
Hello Klin2,
Yes, we do control few GPIO pins which deals with power. The following are the GPIO’s that we set value from our processor application.
PWR_ON_N - set to high by default on application power up in main processor.
RESET_IN_N set to low by default on application power up in main processor.
from the technical specification I understand that
“The PWR_ON_N pad has the minimum assertion time requirement of 25ms, with LOW active. Once the valid power on trigger is detected, the PWR_ON_N pad status can be left open”
Does this mean that the PWR_ON_N should be low for 2 sec within 25 ms ,after VBAT is powered ?
Is this a new assertion which was not there in A2.10.4 version of firmware?
Yes, If I use a different module (HL7688, I do not have A2.10.4 firmware handy, so i cannot downgrade a module which is upgraded) with A2.10.4 firmware, it always works.
More information
Firmware A2.10.4 response to GPIO control.
root@nup-am3517:~# echo 0 > /sys/class/gpio/gpio89/value (Power_ON_N)
root@nup-am3517:~# echo 0 > /sys/class/gpio/gpio90/value (VBATT)
[ 383.411058] usb 1-1: USB disconnect, device number 9
root@nup-am3517:~# echo 1 > /sys/class/gpio/gpio90/value (VBATT)
root@nup-am3517:~# echo 1 > /sys/class/gpio/gpio89/value (Power_ON_N)
[ 402.567698] usb 1-1: new high-speed USB device number 10 using ehci-omap
[ 402.759066] usb 1-1: New USB device found, idVendor=8087, idProduct=0716
[ 402.765881] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[ 405.165048] usb 1-1: USB disconnect, device number 10
[ 408.007698] usb 1-1: new high-speed USB device number 11 using ehci-omap
[ 408.207354] usb 1-1: New USB device found, idVendor=1519, idProduct=0443
[ 408.214221] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 408.226731] usb 1-1: Product: HL7xxx
[ 408.234309] usb 1-1: Manufacturer: Sierra Wireless Inc.
[ 408.245503] usb 1-1: SerialNumber: 014711000500351
[ 408.293724] cdc_acm 1-1:1.0: ttyACM0: USB ACM device
[ 408.316943] cdc_acm 1-1:1.2: ttyACM1: USB ACM device
[ 408.371160] cdc_acm 1-1:1.4: ttyACM2: USB ACM device
Firmware A2.15.0
root@nup-am3517:~# echo 0 > /sys/class/gpio/gpio89/value (Power_ON_N)
root@nup-am3517:~# echo 0 > /sys/class/gpio/gpio90/value (VBATT)
[ 98.368297] usb 1-1: USB disconnect, device number 2
root@nup-am3517:~#
root@nup-am3517:~#
root@nup-am3517:~# echo 1 > /sys/class/gpio/gpio90/value (VBATT)
root@nup-am3517:~# echo 1 > /sys/class/gpio/gpio89/value (Power_ON_N)
root@nup-am3517:~#
[ 119.166030] usb 1-1: new high-speed USB device number 3 using ehci-omap
[ 119.357292] usb 1-1: New USB device found, idVendor=8087, idProduct=0716
[ 119.364103] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
Thanks
Harish K
Hi Harish,
Thanks for your logs.
We have fixed a similar issue in INT7160ATT-2162.
In FW>=A.2.11, module cannot boot up when power up with GPIO_1 or GPIO_5 pull low.
Issue now is fixed on A.2.20.1
Please try test in A.2.20.1. (You should remove .z in the filename then unzip them)
RHL75xx.A.2.20.151600.201903181615.x7160_1_signed.7z.001.z (4 MB) RHL75xx.A.2.20.151600.201903181615.x7160_1_signed.7z.002.z (4 MB) RHL75xx.A.2.20.151600.201903181615.x7160_1_signed.7z.003.z (343.3 KB)
Thank you Klin2. I will try the build and let you know the results.
Hello Klin2,
I was not able to update the software as the model is different. I am working on HL7688 not HL75xx. I have attached the screenshot of the error message for your information.
Is there a fix for the HL7688 version which I could test to see if the problem is fixed?
I would like to ask you, is there a workaround with the existing build A2.15.1 which we could perform to fix the problem?
Thanks
Harish K
Hi Harish,
Sorry my mistake. Fix is ready for HL7588, not HL688.
WIth A2.15.1, to workaround this issue, please make sure not pull low for GPIO_1 and GPIO_5 during boot up.
Klin2,
Thanks for the update . currently in our board GPIO_1 and GPIO_5 are both not connected and its open. So as per your suggestion do we need to put a 1.8v for both these gpios?
Thank you Klin2. We are able to get the work around fix the problem for us.
Is there a plan to release the fix for HL7688? If so is there a timeline by which we can expect the release?
Thank you once again and appreciate you help!!
Hi Harishk07,
We’ve reported the HL7688 issue to R&D. But cannot know the exact timeline of the release.
Thank you for all your help!