GOOD NEWS. I have something that fixes the issue. I am running a 3.5 24V ODrive, and I realized that if you flash the firmware back to 0.3.6 (I know that theres no 3.5 file so I just used the 3.4 24V hex file) the ODrive will connect. I don’t know what really changed from there to 0.4.0 that causes it to not work well but I think @madcowswe will be able to figure it out eventually.
Thanks, I’m sure that will help, at least gives a finite span of the kinds of bugs that could be the issue.
Hi, I just reset the firmware version to 8fc3a43 and build it again.
1 Like
Those of you having issues, can you try disabling the CDC device that ODrive exposes, please? It’s the one labeled “ODrive 3.5 CDC Interface”, or if not named on Windows it’s exposed as a “USB Serial Device (COMx)” under the Ports (COM & LPT) in Device Manager.
I’ve been tracking down this issue on my machine for a couple hours now and want to confirm it’s the same issue ya’ll are experiencing. If it is, then disabling that device/driver should allow you to connect via odrivetool using the existing code from the devel branch.
Hi,
I am too having issues connecting with odrivetool.
I can use the odrive with arduino and serial but I want to work directly in Python.
This is what dmesg says
[ 2088.676511] usb 3-1: new full-speed USB device number 14 using xhci_hcd
[ 2088.806537] usb 3-1: New USB device found, idVendor=1209, idProduct=0d32
[ 2088.806541] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 2088.806544] usb 3-1: Product: ODrive 3.5 CDC Interface
[ 2088.806546] usb 3-1: Manufacturer: ODrive Robotics
[ 2088.806547] usb 3-1: SerialNumber: 365E33593037
[ 2088.807175] cdc_acm 3-1:1.0: This device cannot do calls on its own. It is not a modem.
[ 2088.807198] cdc_acm 3-1:1.0: ttyACM5: USB ACM device
I used already used 3 computers which have 1 common thing Debian.
Any help is appreciated.
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