python-evic
python-evic copied to clipboard
Ban3
Device disconnected during reset
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.
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.
Given that APROM upload works without reset on your device, does it boot LDROM automatically after writing data flash (blank display)?
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.
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.
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.
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.
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.
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.
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.
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).
Bonkers is a big word, it'll just refuse to take any more commands from usb until I pull the cable out and put it back. [spam] Py-hidapi is broken on my linux actually, I've been lazy to debug it. Thanks for that table man :). [/spam]
@netman69 The official updater also sleeps a bit before writing the data flash, that's probably why. If you ever get around debugging cython-hidapi issues I'm interested to hear about it.
My problems with cython-hidapi are most probably pebcak, it's yelling at me about undefined symbols from libusb - must be using the wrong versions of stuff.