I was also having the same issue as @alan on Ubuntu 16.04 and v4.1 of the firmware. Based on the suggestion from @metanoic, I added ENV{ID_MM_DEVICE_IGNORE}="1" to the udev rule, so that modem manager ignores the device. This seems to fix the problem for me. I tried a few things before this, so hopefully it working isn’t a combination of previous debugging steps.
1 Like
@metanoic dug deep with the debugger and was able to find a race condition that could very well be the cause of this issue. Thanks!
Therefore I think @tamecoffee’s workaround is likely to work. Hopefully we will be able to make a proper fix soon.
Depends on your operating system. If linux or mac I can’t advise, but on Windows you’d be looking for it in the Device Manager .
Hi all, all wired up but alas after 3 days I have NO response from ODrive to motor movement; 3 PC’s 3 OS, and not a bleedin thing 
And not for the want of trying, I’ve tried everything from support, and left no text stay hidden, however, I have learned to type odrivetool lightning fast 
Out of all that time, I have this (attached) to ponder over 
The closest I have to working is a new install Ubuntu 18.04, and following is some text that you bright people may decipher.
Bus 002 Device 010: ID 1209:0d32 InterBiometrics
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 239 Miscellaneous Device
bDeviceSubClass 2 ?
bDeviceProtocol 1 Interface Association
bMaxPacketSize0 64
idVendor 0x1209 InterBiometrics
idProduct 0x0d32
bcdDevice 3.00
iManufacturer 1 ODrive Robotics
iProduct 2 ODrive 3.5 CDC Interface
iSerial 3 205C36873548
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 106
bNumInterfaces 3
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xc0
Self Powered
MaxPower 100mA
Interface Association:
bLength 8
bDescriptorType 11
bFirstInterface 0
bInterfaceCount 2
bFunctionClass 2 Communications
bFunctionSubClass 2 Abstract (modem)
bFunctionProtocol 1 AT-commands (v.25ter)
iFunction 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 2 Communications
bInterfaceSubClass 2 Abstract (modem)
bInterfaceProtocol 1 AT-commands (v.25ter)
iInterface 0
CDC Header:
bcdCDC 1.10
CDC Call Management:
bmCapabilities 0x00
bDataInterface 1
CDC ACM:
bmCapabilities 0x02
line coding and serial state
CDC Union:
bMasterInterface 0
bSlaveInterface 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0008 1x 8 bytes
bInterval 16
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 10 CDC Data
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Interface Association:
bLength 8
bDescriptorType 11
bFirstInterface 2
bInterfaceCount 1
bFunctionClass 0 (Defined at Interface level)
bFunctionSubClass 0
bFunctionProtocol 0
iFunction 6 ODrive 3.5 Native Interface
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 0 (Defined at Interface level)
bInterfaceSubClass 1
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Device Status: 0x0001
Self Powered
Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Couldn't open device, some information will be missing
We are working on a fix to an issue which we think is causing this. You can subscribe to it on github. Meanwhile, you can try these workarounds:
- on Windows: try to disable the ODrive CDC Interface in device manager
- on Linux: try @tamecoffee’s solution:
Speaking of which, @tamecoffee do you mind elaborating how exactly to do this? Is it just like this?
We have implemented the separate buffers now on the devel branch. Can someone who knows how to flash devel onto the board see if this fixed the problem?
Thanks.
I flashed devel and it seemed to fix the problem.
1 Like
is the fix merged in production branch now?
Hi,
I have just installed a new computer and are unable to connect to Odrive with the tool. It works fine on my other pc, I’m completely lost as how to get it working on my new pc. Here’s what I get when I run in verbose mode, plugging in the Odrive right after starting the tool:
(base) C:\Users\Ryan>odrivetool -v
ODrive control utility v0.4.6
Waiting for ODrive…
USB discover loop
Please connect your ODrive.
You can also type help() or quit().
USB discover loop
USB discover loop
USB discover loop
USB discover loop
ConfigurationValue 1
InterfaceNumber 0,0
EndpointAddress 130
InterfaceNumber 1,0
EndpointAddress 1
EndpointAddre
EndpointAddress for writing 1
EndpointAddress for reading 129
Connecting to device on USB device bus 0 device 1
no response - probably incompatible
After this it starts going back in to the discover loop until I un-and-replug the usb cable, power cycle the o-drive or restart the tool.
I tried above suggestion to disable the CDC device in device manager, but with that disabled the tool never gets out of usb discover loop.
I have made a wireshark capture as well of me plugging in the device, but I’m not able to attach it to this post.
I have also upgraded the Odrive to the lates firmware, but this did not make a difference.
Any Ideas?? Thank you!
additional Note, I was able to use my new pc to upload the firmware using the ST DfuSe tool, so seems as though at least it can communicate ok ruling out any bad cabling /port etc.
I just go my odrive 3.5 and trying to connect via the odrivetool on Ubuntu 18.04.
It does not work, however many times I try. It shows up under lsusb, though.
It seems to be the issue discussed here.
Running
$odrivetool -v shell
gives
ODrive control utility v0.4.6
Waiting for ODrive…
USB discover loop
ConfigurationValue 1
InterfaceNumber 0,0
EndpointAddress 130
InterfaceNumber 1,0
EndpointAddress 1
EndpointAddress 129
InterfaceNumber 2,0
EndpointAddress 3
EndpointAddress 131
Please connect your ODrive.
You can also type help() or quit().
Kernel Driver was not attached
EndpointAddress for writing 3
EndpointAddress for reading 131
Connecting to device on USB device bus 1 device 26
But no success, never.
How can I upgrade the firmware (which might solve the issue) when I cannot connect at all?
I could solve the issue by upgrading to the latest firmware using Windows.
In Windows, upgrading via the odrivetool did not work, but going through the ST tool did the trick. Thanks for the pretty comprehensive instructions!
With the latest firmware flashed it so far works both on Windows 10 and Ubuntu 18.
1 Like
This would point to perhaps your computer is not using the correct usb driver, as the ST DfuSe tool uses the default usb driver and odrivetool requires a different driver, using the Zadig tool to change driver assignment, just an idea
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