EM7455 failing to upgrade with new release.

[Aleksander Morgado]

Hey!

> 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?
> The error received is error: unsupported download protocol. Verbose output is below.
>
> On an identical system (same hardware, OS, drivers etc) with another EM7455 the upgrade worked. Output also below.
>

Were you attempting upgrade of two different EM7455 modules with
different firmware versions? I wonder if there is some kind of pattern
here.
Also, maybe we should update the tool to allow "forcing" the use of a
given upload protocol in addition to auto-guessing by default, for
cases like this?

> download mode detected
> [04 Oct 2019, 15:02:21] [Debug] [qfu-udev] event: bind 2-4:1.0
> [04 Oct 2019, 15:02:21] [Debug] [qfu-sahara-device] opening TTY: /dev/ttyUSB3
> [04 Oct 2019, 15:02:21] [Debug] [qfu-sahara-device] setting terminal in raw mode...
> [04 Oct 2019, 15:02:21] [Debug] [qfu-sahara-device] waiting time for device to boot properly...
> [04 Oct 2019, 15:02:23] [Debug] [qfu-sahara-device] initializing sahara protocol...
> [04 Oct 2019, 15:02:26] [Debug] [qfu-updater] sahara device creation failed: no sahara response received
> [04 Oct 2019, 15:02:26] [Debug] [qfu-qdl-device] opening TTY: /dev/ttyUSB3
> [04 Oct 2019, 15:02:26] [Debug] [qfu-qdl-device] setting terminal in raw mode...
> [04 Oct 2019, 15:02:26] [Debug] [qfu,dload-message] sent sdp:
> [04 Oct 2019, 15:02:26] [Debug] [qfu-qdl-device] >> 70:00:00 [3, unframed]
> [04 Oct 2019, 15:02:26] [Debug] [qfu-qdl-device] >> 7E:70:00:00:14:46:7E [7]
> [04 Oct 2019, 15:02:26] [Debug] [qfu-qdl-device] << 13:70:00:00:6A:9A:7E [7]
> [04 Oct 2019, 15:02:26] [Debug] [qfu-qdl-device] << 13:70:00:00 [4, unframed]
> [04 Oct 2019, 15:02:26] [Debug] [qfu-updater] qdl device creation failed: unexpected response received in dload sdp: 0x13
> error: unsupported download protocol

This is where the error is, and it's weird, that 0x13 byte is breaking
the flow because we expected 0x02 ("ack") instead.

-- 
Aleksander
https://aleksander.es