we attempted to evaluate the Quectel EG91 firmware EG91EFBR06A07M4G_01.007.01.007.zip (obtained from a Quectel contact) by flashing a modem which had firmware “A04” on it with this firmware image.
As the modem is built into our ARM/Linux device (i.MX6 with Linux 4.9), we obtained the QFlash for Linux package “LTE<E-A_QFlash_Linux&Android_V2.0_20190604-1618.zip” from the sharepoint link posted in this thread: Update the firmware of BG96 via the filesystem
The precompiled QFlash binary from that package was pushed on the device as well as the unpacked firmware zip’s contents, and the update started with the command:
03-31_09:35:21:070] QFlash Version: LTE<E-A_QFlash_Linux&Android_V2.0.0
[03-31_09:35:21:072] Builded at: Jun 4 2019 16:18:03
sh: dpkg: not found
[03-31_09:35:21:127] Host runtime enviroment check ok
[03-31_09:35:21:127]
[03-31_09:35:21:127] The CPU is little endian
[03-31_09:35:21:127]
[03-31_09:35:21:127] ------------------
[03-31_09:35:21:127] User: root
[03-31_09:35:21:127] Group: root
[03-31_09:35:21:127] ------------------
[03-31_09:35:21:127] will write progress status 0% into /data/update.conf
[03-31_09:35:21:128] Warn: Fail to open(O_WRONLY) pipe “/data/update.conf”
[03-31_09:35:21:128] Module upgrade tool, Wed Mar 31 09:35:21 2021
[03-31_09:35:21:128] Auto detect Quectel modem port = ttyUSB3
[03-31_09:35:21:129] Detect /application/data/quectel_update//md5.txt file.
[03-31_09:35:21:129] md5 checking enable.
[03-31_09:35:21:129] md5 checking: /application/data/quectel_update//contents.xml pass
…
[03-31_09:35:23:761] find firehose directory!
[03-31_09:35:23:762] firehose files check pass
[03-31_09:35:23:763] file total size: 212349035
[03-31_09:35:23:764] module platform : 9X07
[03-31_09:35:23:766] product model = Android
[03-31_09:35:23:767] D: /dev/bus/usb/001/002 idVendor=2c7c idProduct=0191
…
[03-31_09:36:09:730] [041.749] send finished
[03-31_09:36:09:732] [041.750]
[03-31_09:36:09:732] [041.751]
[03-31_09:36:09:733] [041.752]
[03-31_09:36:09:735] [041.754]
[03-31_09:36:09:736] [041.755]
[03-31_09:36:10:746] [042.762] inf[0] ep_in -1/1024, errno = 108 (Cannot send after transport endpoint shutdown)
[03-31_09:36:10:746] [042.762] qusb_noblock_read read=-1, errno: 108 (Cannot send after transport endpoint shutdown)
[03-31_09:36:10:746] [042.762] qusb_noblock_read cur=0, min_size=1
[03-31_09:36:10:747] [042.762] ./firehose/firehose_protocol.c fh_recv_cmd 320 fail
[03-31_09:36:10:747] [042.762] THE TOTAL DOWNLOAD TIME IS 42.757 s
[03-31_09:36:10:747] [042.762] Upgrade module successfully.
[03-31_09:36:10:747] Upgrade module successfully, Wed Mar 31 09:36:10 2021
[03-31_09:36:10:747] THE TOTAL DOWNLOAD TIME IS 49.619 s
Unfortunately, this is the last that has been “seen” of this modem. We’ve tried to power it off completely, retried the power-on sequence over and over again, but NOTHING shows up on the USB port the modem is connected to anymore.
Questions:
Is there a way to recover this device? I would not know how if it does not show up at all anymore.
What did we do wrong? Is it possible to update a Quectel EG91 from firmware A04 to A07? How? Before we retry this with another device/modem, we’d like to be sure we do not repeat the same mistake.
Best Regards,
Robert Schlabbach
Senior Architect and Embedded Software Developer
ubitricity is a wholly-owned subsidiary of Shell.
ubitricity Gesellschaft für verteilte Energiesysteme mbH
Hi,
Thanks for your query in Quectel forums.
Please send the specific version number information before the module upgrade, it is best to use AT command to send ATI to get the specific version information,thanks.
Hi,
So now there is no USB port of the module in the device manager, and the software version cannot be rolled back? I think it may be caused by something wrong during the upgrade process.
thanks.
Same problem here, but not solved yet.
Techinical support is ongoing.
Modem: EG91-E Hw revision: FB Original firmware: EG91EFBR06A04M4G. OS: Linux Yocto Update applications: I used both QFirehose 1.4.5 and Quectel_LTE_QFlash_Linux&Android_V1.4.8) Trialed Firmwares: EG91EFBR06A05M4G, EG91EFBR06A06M4G and EG91EFBR06A07M4G
The update process seems to be ok.
After reboot the modem connects to USB but after 5 seconds it disconnects and never connect again, not even after a reboot or after removing VBAT.
During these 5 seconds I am able to query the firmware version which is, as expected, the “new” one.
If I program the original firmware the modem resumes correct operation.
We are able to program the modem multiple times managing the signal USB_BOOT that permit to perform emergency downloads thanks to Qualcomm bootloader.
Quectel technician requested to verify VBUS signal on the USB interface to be correctly ON (it’s ok on my hw).
@Kerr.Yang-Q, yes, we do not see any USB device at all any more, not even briefly after power up. The modem appears to be “dead”, or “bricked”.
@luca, thank you very much for your response, so it seems this is not our fault, but rather Quectel EG91-E firmware A04 cannot be updated using the existing flashing tools & firmware images. Also thanks for the pointer to the USB_BOOT signal, I’ll check with our HW engineers if we can get to that pin and at least recover our bricked device.
@Kerr.Yang-Q we’re stuck here. We cannot order more EG91-E without first qualifying the new A07 firmware with our devices, and we cannot update the modems we already have. What solution can you offer?
Best Regards,
Robert Schlabbach
Senior Architect and Embedded Software Developer
ubitricity is a wholly-owned subsidiary of Shell.
ubitricity Gesellschaft für verteilte Energiesysteme mbH
For posterity’s sake:
The issue is related to USB configuration.
In firmware revision A05 Quectel added support for UAC to USB configuration (see release notes, 4th item at page 4 is "Supported UAC by AT command AT+QCFG=“usbcfg”).
Supporting UAC made it necessary to add one more field to “usbcfg” parameter.
Until revision A04 configuration “usbcfg” was made of 8 parameters (vid, pid, diag, nmea, at_port, modem, net, adb).
Starting from revision A05 configuration “usbcfg” is made of 9 parameters (vid, pid, diag, nmea, at_port, modem, net, adb, uac).
Switching back and forth between revision A04 and A05, and changing usbcfg params, it becomes clear that the two revisions store such parameters in two different NV memory locations.
Apparently the addition of the ninth parameter forced Quectel to move the configuration to a new memory area, but they didn’t think about keeping the old configuration.
Modems manufactured with revision A04, when upgraded to A05 or later, will set usb configuration to “all usb ports disabled” (due to new memory area not initialized, I suppose).
The issue cannot be replicated with modems manufactured with revision A05 or newer because they would have the memory location of the 9-params configuration already initialized.
After more than a year and hundredths of hours spent by my team to demonstrate the issue to Quectel technicians, a few months ago they were able to reproduce the issue and just said they do not plan to solve it.
In my opinion Quectel have put very little effort in trying to understand the problem.
A software problem, causing modems to become unresponsive, will not be be fixed.
thank you very much for your detailed answer and the many hours you spent to identify the root cause - apparently with NO substantial help from Quectel.
We will make sure to keep the lack of diligence and support on behalf of Quectel in mind when choosing suppliers for our designs.
Best Regards,
Robert Schlabbach
Senior Architect and Embedded Software Developer
ubitricity is a wholly-owned subsidiary of Shell.
ubitricity Gesellschaft für verteilte Energiesysteme mbH
I’m sorry I just saw this information, I am the R&D of quectel, and I will check the issue ASAP, and give the root reason and the solution how to upgrade the firmware from EG91EFBR06A04M4G to new ones .Sorry again.