Device disconnected during reset

[ReservedField]

If I try to upload any firmware (tested with both eVic and Presa firmwares), the device disconnects during reset. I have the Presa FW installed right now, but it also happens with the eVic one.

$ sudo evic upload somefirmware.bin

Found device:
    Manufacturer: Nuvoton
    Product: HID Transfer
    Serial No: XXXXXXXXXXXX

Reading data flash...

    Device name: Presa TC75W
    Firmware version: 1.02
    Hardware version: 1.01

Writing data flash...

Traceback (most recent call last):
  File "/bin/evic", line 9, in <module>
    load_entry_point('evic==0.1', 'console_scripts', 'evic')()
  File "build/bdist.linux-x86_64/egg/evic/cli.py", line 157, in main
  File "build/bdist.linux-x86_64/egg/evic/device.py", line 205, in reset_system
  File "build/bdist.linux-x86_64/egg/evic/device.py", line 125, in send_cmd
  File "build/bdist.linux-x86_64/egg/usb/core.py", line 878, in write
  File "build/bdist.linux-x86_64/egg/usb/backend/libusb1.py", line 778, in intr_write
  File "build/bdist.linux-x86_64/egg/usb/backend/libusb1.py", line 856, in __write
  File "build/bdist.linux-x86_64/egg/usb/backend/libusb1.py", line 552, in _check
usb.core.USBError: [Errno 19] No such device (it may have been disconnected)

After this obviously it won't work, but it can be brought back to life with the official updater. I worked around this by adding a try/except to the call to dev.reset_system() in cli.py, ignoring the exception. It works fine now, with all kinds of firmwares. Actually, the device disconnecting during reset should be expected. I'm not sure this is the best way to fix it, though.

[Ban3]

Never seen this one. No idea why it can't find the device before reset.

Device disconnect after reset is expected. The program sleeps for few seconds and tries to re-attach the device.

[Ban3]

Given that APROM upload works without reset on your device, does it boot LDROM automatically after writing data flash (blank display)?

[ReservedField]

Yes, it does boot LDROM. At that point flashing with python-evic (even with the reset fix) does not work, it fails on dataflash read IIRC. It will flash by passing a dataflash backup with --dataflash, though. It also works in the official updater. I'll brick the APROM again tomorrow so I can confirm that the dataflash read fails from LDROM. Actually the first thing I tried was increasing both delays to 10 seconds, but that didn't work. Anyway, the backtrace shows that it disconnects while sending the command (write in /usb/core.py), not before or after the reset. Maybe I've got something going on with libusb? I'm on Fedora 23, simply make'd install. I guess catching only the device disconnected exception would be a good enough fix, since if it was really disconnected it would fail in attach() later on anyway.

[Ban3]

Yes, it does boot LDROM.

I'm starting to think it's HW version differences. I have 1.06 and it definitely needs the reset command to change to LDROM

Anyway, the backtrace shows that it disconnects while sending the command (write in /usb/core.py)

I still think it's the data flash write that resets your device. It seems weird it would reset in the middle of writing reset to it.

[ReservedField]

I did a few tests. I removed the reset command after the dataflash write. It does not reset by itself, it stays in APROM (and of course APROM upload fails). Seems like the reset doesn't come from the write.
So I wrote a quick test that only attaches to the device, sends a reset and exits. The device resets and Python gives the "device disconnected" backtrace. It then takes another reset command to bring it back to APROM, of course.
So really, all I can think of is that the device resetting in the middle of the command write. Which doesn't make any sense, since the endpoint handler in the firmware references the whole HID command, which implies it must have been already fully transferred.
The workaround commit does fix this, though.

[Ban3]

That's weird. Seems like the whole reset command gets written but it's still doing something to raise the USBError. It would raise AssertionError if the whole command is not written.

I might have to take a closer look at the reset command at some point. Can't rule out PyUSB, though.

[Ban3]

I'm going to close this one as it refers to the old pyusb days.

[ReservedField]

I'm afraid I still have this issue. It fails in "restarting device", but the device actually goes to LDROM so if I launch python-evic again it flashes. I tried sniffing the USB traffic with Wireshark to find what's going on and it worked fine while usbmon was attached? I don't know, I'll try to debug it later. May just be some screw up on my machine, I'll be doing a clean install on a new laptop in a few days so I'll see if it still happens.

[Ban3]

In that case, reopening. We can rule out pyusb now.

[ReservedField]

We can rule out my eVic being the problem. I still haven't got around to doing a Linux install on my new laptop, but I tested it on Windows + Cygwin and it doesn't disconnect. I think it was just my Linux install having issues. I'll test with a clean Linux install so we can close this for good.

By the way, to get it to work on Cygwin I had to make a few patches to hidapi. This is documented in evic-sdk readme.

[netman69]

I am in the process of writing a flashing tool (cause python is giving me trouble, and the sake of learning) https://bitbucket.org/netman69/evicflash/src
Ran into a very similar problem, which turned to be because the device goes bonkers (on the USB side) if trying to write the dataflash straight after reading it. Inserting a 100ms delay between reading and writing the dataflash fixed it. Not sure if it's the same issue though since in my case I didn't end up in LDROM.

[ReservedField]

Joyetech copypasted Nuvoton's update code which, while being a special kind of crappy, is pretty stable. So I'm actually surprised it goes bonkers. Anyway, I don't think it's related to this problem. It was just my Linux install that was messed up. Is python giving you issues on Windows? If so, take a look at the evic-sdk readme.

By the way, this might interest you (but let's not spam the issue, if you need clarifications my email is in my public profile).