Hi,
I can’t get the ODrive working anymore with USB. I’ve already switched it on and off, I tried it on several computers, but no success. When I plug in the USB cable, I get a warning ‘Unkown USB Device (Device Descriptor Request Failed)’. In Linux the ODrive is not listed under the USB devices.
I ran out of ideas how I could regain the USB connection. Has anyone an idea?
I’de be grateful for advices!
Did you update the odrive Firmware with odrivetool dfu before you got the problem?
Same problem here. Board appears to work correctly and will still run motor calibration at startup, but won’t show up at all over USB. I’ve tried many different cables on both windows and linux. I get the exact same message as you when plugging into windows. I tried to put the board into DFU using the switch but I couldn’t flash it. Hopefully someone can help.
You’ll have to flash it with an alternate DFU tool or an STLink. ODrive Tool | ODrive
You can also check if flashing an older version of the firmware to see if that helps (it’s possible it’s an issue with 0.5.2)
Will this restore USB functionality? Also, do you know why this problem occurs?
I tried reflashing with an STLink by following the tutorial but it didn’t fix the issue.
First I flashed 0.5.2 and then I flashed 0.5.1 but neither worked.
Any other ideas?
If neither 0.5.2 nor 0.5.1 work, you have a different problem. I assume you’re powering the board with > 8V via the Batt terminals, and it’s not in DFU mode?
Yeah, I have the 56V version which I’m powering with a 10S battery (42V max) and the DFU switch is set to RUN.
No, I didn’t update the odrive Firmware. I’m still using 0.5.1
I flashed both the new and old version of the firmware, but I’ve got still the same error. Any ideas what the problem could be?
So, you can’t see the drive on USB, but you can reprogram it with ST-Link? 
Either the USB cable/socket is bad, or the 3.3V regulator is blown, i’d guess.
Use a multimeter and check that you have 3.3V on any of the 3.3V pins.
Hello, you can connect the computer with 0.5.1 USB.
But the 0.5.2 version of USB can not connect to the computer.
I use STLINK to erase the old firmware before refreshing it
Yes, with ST-Link I’m able to flash the firmware.
I checked the voltage between the 3.3V Pin and Ground, I’ve got 3.3V. I’ve already tried multiple USB cables. How can I check if the USB socket is the problem? Or could there be another cause for the problem?
In Linux, what do you see when you run sudo dmesg -w and plug in the ODrive?
Also, what power supply are you using? Is it referenced to mains earth or are you using a battery?
The ODrive doesn’t show up at all. I’ve got a second one with a working usb connection. If I plug in the working ODrive, it shows up under sudo dmesg -w.
The power supply is referenced to mains earth. I’ve also tried another power supply.
Do you have 3.3V and 5V at the appropriate locations? Is the green light turning on? What temperature is the STM chip on the board, if you touch it with your finger?
I guess so, at least I am measuring the right voltage at 3.3V and 5 V Pins. Yes, the green light is turning on. The STM chip is cold.
It is possible that there was a ground loop surge e.g. positive power supply connected before negative side, so the negative current path became the USB cable via mains earth.
It’s possible that such an event could have damaged the USB pins on the microcontroller without destroying the rest of the chip?
Actually, I always connect the ODrive to the power supply before turning it on. But in case I really made a ground loop accidently, how can I verify it? I already checked with a multimeter that the lines from USB to the chip work.
Can you verify that the ODrive itself is actually running, i.e. nothing stupid is going on like your programmer is holding it in RESET?
If you have a scope, check that you have activity on the SPI pins on power-up (it will try to initialise the DRV8301 gate drivers)
If you have a debugger, can you halt the chip and see which line of code it is on? If it’s in something like hardfault_handler then the code has crashed and you could give us a backtrace.
Maybe set a breakpoint in one of the main threads and see if it gets there.
e.g. in usb_server_thread() in Firmware/communication/interface_usb.cpp, or Axis::run_state_machine_loop() in Firmware/MotorControl/Axis.cpp