I’ve been using an ODrive v3.6 for almost a year now without much problems. This time, though, when I tried to connect the ODrive via USB, it wouldn’t show up on the odrivetool. odrivetool just says “Please connect your ODrive.”
I thought there was an issue with either the USB cable of my laptop, so I tried with a different USB cable, and on a different operating system. I tried both Windows and Mac, but neither worked.
I then attempted to put the ODrive into dfu mode in an attempt to reflash the firmware. I toggled the dfu switch and cycled the ODrive, but I couldn’t also detect the ODrive when using dfu-util --list on Mac or Zadig utility on windows.
The green power led on the ODrive lights up, so I’m not really sure what’s the problem here. I’ve spent the whole day being bamboozled by this.
This has happened to me too. You can try 2 things:
- Most of the times you just have to shut down the ODrive and reopen it and then the usb works fine.
2.If the usb isn’t in general visible to your pc, then you just have to flash the ODrive with the STM32CubeProgrammer.
I already tried 1. and it sadly didn’t do anything. For 2., I’m a bit hesitant on spending to buy it if the ODrive board is indeed already bricked. Did this work for you?
You don’t have to buy anything, it’s a free program.
Go where it says Multi-platform and follow the steps. Actually is the only thing that worked for me when usb wasn’t visible.
Sadly, it doesn’t seem to work. When I select USB configuration, nothing shows up. I’ve confirmed the I’ve put (or at least tried to put) the board into DFU mode, and yet won’t show up on the STM Cube Programmer USB selection.
Is there anything else I can do?
Can you try Linux?
e.g. raspberry pi?
libusb really sucks on windows due to microsoft forcing every device to use a different driver. On linux I never have any issues (except permissions: make sure you run
sudo odrivetool udev-setup)
Also, I have sometimes had an issue where the STM32 firmware has been corrupted. This sometimes seems to happen when using a high voltage (50V) power supply.
In this case I have needed to use the DFU switch to force the board to start in DFU bootloader mode. Then
odrivetool dfu Firmware/build/ODriveFirmware.hex works as normal.
I haven’t tried linux; I’ll try after the weekend but I doubt it would make a difference after trying different softwares already on different operating systems.
I’ve also used the DFU switch to no avail before.
Not really sure what to do anymore so I just went ahead and ordered a new board.
At least with Linux, you can see exactly what is going on.
sudo dmesg -w command shows the linux kernel log messages, and it will include what kind of USB device is plugged in, and if it is faulty or not.
If you get USB device descriptor read errors even with the DFU switch set, you should try emailing firstname.lastname@example.org with a link to this thread and they might let you send in your dead board for a free repair (they can revive it with an ST programmer, probably) or if not they will probably refund or replace it.
Yeah, try with the STLink first. We’ve seen issues where the STM chip basically just erases itself.
Thanks, unfortunately I dont have an stlink so I just went ahead and ordered a new board. I still have the old one and I’ll try messing with it if I end up with an stlink in the future.
btw, any ST ‘nucleo’ board comes with an ST-link included, so you can use one of those if you have one
I got an ST-link and managed to refresh a new firmware.
Unfortunately, I also just received the new board ordered, and now I have no use for it. Is there any way to return it? I’ve sent an email too, if that helps.
Email is the right way to go there.