<div dir="ltr">Hey!<div><br></div><div>Have narrowed this down to being a hardware issue with the USB2 lane of that system.</div><div>I imagine the EM7511/7565 upgraded fine because they must stay in superspeed/USB3 while upgrading.</div><div>Seems all is good, apologies!</div><div><br></div><div>--</div><div>Paul</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 8 Oct 2019 at 10:25, Paul Gildea <<a href="mailto:gildeap@tcd.ie">gildeap@tcd.ie</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi Aleksander, <div><br></div><div>Both firmware versions were the same. The upgrades were from 02.24.05.06 GENERIC to 02.30.01.01 VERIZON.</div><div>One consistently works and the other doesn't!</div><div><br></div><div>--</div><div>Paul</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 7 Oct 2019 at 17:27, Aleksander Morgado <<a href="mailto:aleksander@aleksander.es" target="_blank">aleksander@aleksander.es</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hey!<br>
<br>
> Hi, I upgraded to the new release and tested out EM7565/EM7511 firmware upgrades which worked perfectly. However I'm having an issue with EM7455 failing to upgrade now. Any ideas?<br>
> The error received is error: unsupported download protocol. Verbose output is below.<br>
><br>
> On an identical system (same hardware, OS, drivers etc) with another EM7455 the upgrade worked. Output also below.<br>
><br>
<br>
Were you attempting upgrade of two different EM7455 modules with<br>
different firmware versions? I wonder if there is some kind of pattern<br>
here.<br>
Also, maybe we should update the tool to allow "forcing" the use of a<br>
given upload protocol in addition to auto-guessing by default, for<br>
cases like this?<br>
<br>
> download mode detected<br>
> [04 Oct 2019, 15:02:21] [Debug] [qfu-udev] event: bind 2-4:1.0<br>
> [04 Oct 2019, 15:02:21] [Debug] [qfu-sahara-device] opening TTY: /dev/ttyUSB3<br>
> [04 Oct 2019, 15:02:21] [Debug] [qfu-sahara-device] setting terminal in raw mode...<br>
> [04 Oct 2019, 15:02:21] [Debug] [qfu-sahara-device] waiting time for device to boot properly...<br>
> [04 Oct 2019, 15:02:23] [Debug] [qfu-sahara-device] initializing sahara protocol...<br>
> [04 Oct 2019, 15:02:26] [Debug] [qfu-updater] sahara device creation failed: no sahara response received<br>
> [04 Oct 2019, 15:02:26] [Debug] [qfu-qdl-device] opening TTY: /dev/ttyUSB3<br>
> [04 Oct 2019, 15:02:26] [Debug] [qfu-qdl-device] setting terminal in raw mode...<br>
> [04 Oct 2019, 15:02:26] [Debug] [qfu,dload-message] sent sdp:<br>
> [04 Oct 2019, 15:02:26] [Debug] [qfu-qdl-device] >> 70:00:00 [3, unframed]<br>
> [04 Oct 2019, 15:02:26] [Debug] [qfu-qdl-device] >> 7E:70:00:00:14:46:7E [7]<br>
> [04 Oct 2019, 15:02:26] [Debug] [qfu-qdl-device] << 13:70:00:00:6A:9A:7E [7]<br>
> [04 Oct 2019, 15:02:26] [Debug] [qfu-qdl-device] << 13:70:00:00 [4, unframed]<br>
> [04 Oct 2019, 15:02:26] [Debug] [qfu-updater] qdl device creation failed: unexpected response received in dload sdp: 0x13<br>
> error: unsupported download protocol<br>
<br>
This is where the error is, and it's weird, that 0x13 byte is breaking<br>
the flow because we expected 0x02 ("ack") instead.<br>
<br>
-- <br>
Aleksander<br>
<a href="https://aleksander.es" rel="noreferrer" target="_blank">https://aleksander.es</a><br>
</blockquote></div>
</blockquote></div>