Just curious if you have encountered any more issues with detecting the ODrive on your machine. I am on win10 and having similar problems, though firmware update did not solve it. I can communicate with the device fine on another PC, so I know the board is good.
Since the firmware update in October '18 I have not run into any connectivity issues, neither on Windows 10 nor in Ubuntu 18.04.
The only thing I could think of if it does not work for you in Windows 10 is that, maybe, the driver is configured incorrectly?
Yes, I think that is probably the case. Unfortunately I am not sure how to remedy that short of using an entirely different PC. I think the drivers may have gotten screwed up after trying to use a USB hub and many driver reinstall cycles when attempting to get that to work, which I never did.
I suppose its worth mentioning that I used to have a 24V 3.4 board which I was able to get to work months ago, but the native interface was never terribly reliable. If I remember correctly things got screwed up after putting the usbser driver on the CDC interface. I can see the CDC interface when I plug in the board, but sending commands to it with a terminal does nothing. I cannot see the native interface at all.
Are you aware of some method to fix the driver issues? Pardon my ignorance on that, I don’t have much experience with USB. I have uninstalled all of the old ODrive devices that made their way into the device manager in hopes that I could start fresh, but that did not do the trick.
I believe I am having the same problem in Win 10. When attempting to open odrivetool in the anaconda prompt I get the following error.
‘chcp’ is not recognized as an internal or external command,
operable program or batch file.(base) C:\Users\DouReves>odrivetool
ODrive control utility v0.4.7
Exception in thread Thread-1:
Traceback (most recent call last):
File “C:\Users\DouReves\Anaconda3\lib\threading.py”, line 917, in _bootstrap_inner
self.run()
File “C:\Users\DouReves\Anaconda3\lib\threading.py”, line 865, in run
self._target(*self._args, **self._kwargs)
File “C:\Users\DouReves\Anaconda3\lib\site-packages\fibre\usbbulk_transport.py”, line 191, in discover_channels
devices = usb.core.find(find_all=True, custom_match=device_matcher)
File “C:\Users\DouReves\Anaconda3\lib\site-packages\usb\core.py”, line 1263, in find
raise NoBackendError(‘No backend available’)
usb.core.NoBackendError: No backend availablePlease connect your ODrive.
You can also type help() or quit().In [1]:
I got the same error after disabling the USB Serial Device in the device manager.
When attempting to update firmware, I recieved the following:
(base) C:\Users\DouReves>odrivetool dfu
ODrive control utility v0.4.7
Waiting for ODrive…
Exception in thread Thread-2:
Traceback (most recent call last):
File “C:\Users\DouReves\Anaconda3\lib\threading.py”, line 917, in _bootstrap_inner
self.run()
File “C:\Users\DouReves\Anaconda3\lib\threading.py”, line 865, in run
self._target(*self._args, **self._kwargs)
File “C:\Users\DouReves\Anaconda3\lib\site-packages\fibre\usbbulk_transport.py”, line 191, in discover_channels
devices = usb.core.find(find_all=True, custom_match=device_matcher)
File “C:\Users\DouReves\Anaconda3\lib\site-packages\usb\core.py”, line 1263, in find
raise NoBackendError(‘No backend available’)
usb.core.NoBackendError: No backend availableException in thread Thread-1:
Traceback (most recent call last):
File “C:\Users\DouReves\Anaconda3\lib\threading.py”, line 917, in _bootstrap_inner
self.run()
File “C:\Users\DouReves\Anaconda3\lib\threading.py”, line 865, in run
self._target(*self._args, **self._kwargs)
File “C:\Users\DouReves\Anaconda3\lib\site-packages\odrive\dfu.py”, line 438, in find_device_in_dfu_mode_thread
devices[0] = find_device_in_dfu_mode(serial_number, find_odrive_cancellation_token)
File “C:\Users\DouReves\Anaconda3\lib\site-packages\odrive\dfu.py”, line 241, in find_device_in_dfu_mode
stm_device = usb.core.find(idVendor=0x0483, idProduct=0xdf11, **params)
File “C:\Users\DouReves\Anaconda3\lib\site-packages\usb\core.py”, line 1263, in find
raise NoBackendError(‘No backend available’)
usb.core.NoBackendError: No backend available
I received the same error after placing the DIP switch to DFU, power cycling the board, and placing the DIP switch back to RUN and power cycling the board again according to the firmware update trouple shooting guide.
@madcowswe What build environment are you using for your development? I was running into the same problem that others have had on this thread and at least in my case it seems to be somehow related to my build environment. When I grab the v0.4.7 ELF from the releases page on Github and program that onto my ODrive v3.5 everything works fine. Alternatively, if I checkout the fw-v0.4.7 tag in git and do my own build, the USB communication doesn’t seem to work.
I am using the following:
MacOS Sierra 10.12.6
arm-none-eabi-gcc (GNU Tools for Arm Embedded Processors 8-2018-q4-major)
tup UH��H�� <-- ?? Not sure what this is about, it is the output from tup --version, brew claims 0.7.8
Open On-Chip Debugger 0.10.0
Python 3.7.0
GNU Make 3.81
I have had CONFIG_USB_PROTOCOL set to native-stream for all of the different builds that I have tried.
Whenever I do a build I do get a bunch of tup warnings saying that certain build files were modified outside of tup. Not sure if that is an indication of anything or not.
Are you seeing anything about my environment that might be the cause of my problems?
Thanks,
Ryan
I have a quick update for anyone else that are doing builds on macos. It looks like the instructions in the documentation to set CONFIG_USB_PROTOCOL equal to native-stream was the source of my problems with the USB communication. I haven’t had a chance to fully dig into things yet, but as soon as I switched back to CONFIG_USB_PROTOCOL=native I was at least able to get my odrive to initially show up in odrivetool.
I don’t currently understand the implications between the two different settings, so if I have some time I will dig into that a bit more.
Btw, GCC 8 does not currently work with the code (at least not on windows). Make sure you’re using GCC 7.x
I’m having this issue with v3.6 24V. I flashed the latest firmware with st-link/v2 and it didn’t solve it. I get this error:
(base) C:\WINDOWS\system32>odrivetool -v
ODrive control utility v0.4.11
Waiting for ODrive...
USB discover loop
ConfigurationValue 1
InterfaceNumber 0,0
EndpointAddress 130
InterfaceNumber 1,0
EndpointAddress 1
EndpointAddress 129
EndpointAddress for writing 1
EndpointAddress for reading 129
Connecting to device on USB device bus 0 device 1
C:\ProgramData\Anaconda3\lib\site-packages\fibre\shell.py:104: RuntimeWarning: coroutine 'InteractiveShell.run_code' was never awaited
console.runcode('import sys')
RuntimeWarning: Enable tracemalloc to get the object allocation traceback
C:\ProgramData\Anaconda3\lib\site-packages\fibre\shell.py:105: RuntimeWarning: coroutine 'InteractiveShell.run_code' was never awaited
console.runcode('superexcepthook = sys.excepthook')
RuntimeWarning: Enable tracemalloc to get the object allocation traceback
C:\ProgramData\Anaconda3\lib\site-packages\fibre\shell.py:106: RuntimeWarning: coroutine 'InteractiveShell.run_code' was never awaited
console.runcode('def newexcepthook(ex_class,ex,trace):\n'
RuntimeWarning: Enable tracemalloc to get the object allocation traceback
C:\ProgramData\Anaconda3\lib\site-packages\fibre\shell.py:109: RuntimeWarning: coroutine 'InteractiveShell.run_code' was never awaited
console.runcode('sys.excepthook=newexcepthook')
RuntimeWarning: Enable tracemalloc to get the object allocation traceback
Please connect your ODrive.
You can also type help() or quit().
no response - probably incompatible
USB discover loop
USB discover loop
My device manager shows:
Any ideas?
I can get the board running with arduino via uart. Works in sensorless mode, voltage measurement, calibration…