ODrive DFU issue

Hi everybody.
Got such issue with ODrive.
After trying to reflash the board with orivetool dfu it freezes on discover.
After killing the process board now shown with lsusb as follows:
Bus 001 Device 009: ID 0483:df11 STMicroelectronics STM Device in DFU Mode

I was lucky to flash new FW with dfu-util
But board still keeps in dfu mode and can’t be connected via odrivetool or recognized via odrivetool dfu.

What should I do?
How to put it back to normal operation?

Kind regards.

1 Like

The switch on the board is in RUN mode?

Switch is in RUN mode, but board is not shown in lsusb now …
While switching to DFU, it appears with STM in DFU mode, but not recognizable by odrivetool dfu …
with dfu-util I can flash corresponding hex with success, but after switching to RUN - no board…

Hmm… Curious. Does it show up in Zadig?

I’m having the same issue, I checked after switching from RUN to DFU and it now appears as:

Bus 001 Device 012: ID 0483:df11 STMicroelectronics STM Device in DFU Mode

I haven’t tried flashing with dfu-util but I can confirm odrivetool is now stuck on the:
“Downloading json data from ODrive… (this might take a while)”
command when connecting the board. I tried it with Zadig and it does show up. I posted the errors in a new issue (#509)

You’ll only be able to download the JSON in RUN mode. Make sure only the native interface is set to libusb, and the CDC interface should be “usbser” or WinUSB or whatever the default is.

1 Like

I only get to the “Downloading json data from ODrive… (this might take a while)” line when it’s in RUN mode (in DFU it isn’t recognized at all by odrivetool). It was also getting stuck on the downloading line before I played around with Zadig, since I initially tried it out with linux. Regardless, I will check that both of those drivers line up.

So, seems it’s come time to ST-Link? )

I’ve the same issue, after pip install --upgrade odrive, it shows "“Odrive control utility v0.5.1” but afterward, it stuck in “Downloading json data from Odrive…” forever (I wait 3 hours before hard shutdown)
Now I need to use another computer with old utility (0.4.1) to connect to the updated Odrive board (fw_version 0.5.1)

@maxwlchow Try running odrivetool in verbose mode:

odrivetool --verbose

I actually ran into an issue where I had previously run odrivetool with sudo and it caused my permissions to get messed up. If you get some error about permissions it’s likely a quick fix.

Thanks for your suggestion but I am using anaconda under windows, odrivetool --verbose doesn’t work. I must use odrivetool shell to get into the utility before

Please try to upgrade the odrivetool again, we just updated it to hopefully fix this “forever waiting for JSON” problem.

ST-Link flash solved the issue.

1 Like

I can finally run into the shell again after update the odrivetool but it takes few minutes every time I start the tool. After “Downloading json data from Odrive…”, it will show "Failed to cache JSON: makdires() got an unexpected keyword argument ‘exist_ok’
BTW, I am still unable to use live plotter, it will still loop in “Downloading json data from Odrive…”

Well it should be mkdirs(), and exist_ok is a keyword that allows the directory to exist when being created without throwing a warning.

What version of Python are you using? And make sure that only the Native Protocol is setup for libusb in zadig, not the CDC protocol (which should be WinUSB or usbser)

I am using python 2.7.14, I have this problem after updated to 0.5.1

Sorry, Python 2 is not supported. Please use Python 3.8