Dear fellow forum inhabitants,
I’ve managed to brick one piece of the MC8092 in a curious way… (curious to me, anyway). The card is now in the Qualcomm “emergency downloader” mode, visible on the USB bus, but apparently I don’t have the right tools or ROM contents to talk to it. Any help would obviously be welcome.
Boring details follow. This is essentially a side-plot to my recent topic:
In an attempt to reproduce the misbehavior observed by my customer, I have taken out a fresh VTC6210 (Nexcom PC) and a fresh MC8092 from stock. The Sierra was a last piece in our stock, from a recentish delivery from Nexcom.
I went on to l “deploy” WES7 on the hardware from a backup.
So far it’s business as usual.
Next, I knew I had to switch the Sierra card from Direct IP mode into QMI mode. We do this routinely for Win7/WES7.
Interesting - 14 other pieces, just delivered to the customer, switched to PID 9011 just fine.
Turns out that this piece of the MC8092 contained firmware 184.108.40.206 ex factory.
Serial number : CEC3435013210
The 14 pieces recently shipped to the customer have FW P02.04.04.00 ex factory.
As I’ve written before, I’ve already found an image of the P02.04.04.00 at
source.sierrawireless.com/resou … ,00_00-fw/
So I decided to flash that.
While googling around a bit, I also found a related and relevant “migration guide”:
source.sierrawireless.com/~/med … ev2_5.ashx
Read the whole paper, nothing to suggest that the upgrade should be a problem (except maybe for a note saying that original MC9090/SL9090 were not eligible for the update, but no such note about the MC8092/SL8092.)
The old hardware had MSM6200, the “respin” has MSM6600, supposedly nearly identical.
Okay, let’s give it a go.
I unpacked the P02.04.04.00 RAR file, and the EXE files included, and ended up with a subdirectory containing the GUI-based BinUpdater.EXE and the command-line based FDT.EXE. And, several CWE files.
I started with BinUpdater, tried the boot.cwe.
That failed to flash (refused by the current firmware, apparently).
I went on to try the appl.cwe using BinUpdater.
That uploaded and apparently some flashing activity went on.
Early during that process, the modem vanished from USB and reappeared as a Qualcomm USB/Serial “emergency downloader stub”.
And, that was the end of it.
I waited 30 minutes and power-cycled the PC. That had no effect, the modem is still in the “emeregency download mode”.
A quick google found out that people can unbrick Qualcomm-based phones that drop into this mode for some reason. But it takes dedicated ROM files for the specific platform/phone/MT model.
Well at least I found some Windows drivers for the “Qualcomm emergency downloader” USB/serial device.
I went on to try launching “fdt.exe” manually from command line, adding a file name as its only argument. I passed the longest CWE file to it (figuring that it’s one big image, bootloaer + “apps”).
Apparently fdt.exe managed to find the Qualcomm emergency device and talk to it, but returned early with an error message “Received NAK response in DMSS download protocol.”
I also tried uploading the boot.cwe in this way, with the same outcome.
Again some hacker fora mention interesting details about the DMSS protocol, but not nearly enough for me to unbrick
the Sierra card. Enough for me to understand that without effective help from Sierra, I alone won’t make it.
forum.xda-developers.com/showth … 142&page=3
At this point in my trouble case, my customer is willing to get rescued by a modem from a different vendor. And I do have some in the lab for evaluation. It’s unfortunate that this “industrial” market is such a niche. Sierra’s public techsupport is still about the best