it won’t let me run the odrivetool under sudo, looks like it doesn’t recognize the command? it returns:
sudo: overivetool: command not found
As i mentioned, i have another board, and it seems to work fine on that one, the command works just fine, i just don’t update because it’s already at v0.5.1
this is the command i use with the ST-LINK…
$ openocd -f interface/stlink-v2.cfg -f target/stm32f4x.cfg -c init -c “reset halt” -c “flash write_image erase ODriveFirmware_v3.5-24V.elf” -c “reset run” -c exit
…a get this…
i get the same on both linux and macos
If you have cloned the git repo (git clone https://github.com/madcowswe/ODrive.git),
you can run it with
sudo python3 tools/odrivetool dfu
but if it works on the other board, that is strange.
It could still plausibly be a different device descriptor, i.e. a different version of the DFU bootloader on the two chips, that could cause a permissions issue though.
I take it you have tried the DFU switch? (this will put it into DFU mode on power-up)
Also, you can try manually calling odrv0.enter_dfu_mode() from the odrivetool shell
(make sure you back up your config if you want to keep it)
1 Like
Cool! No, i have not tried manually calling odrv0.enter_dfu_mode(); i’ll try that. I’ll keep you posted. THANK YOU!
FYI- I tried
$ sudo python3 tools/odrivetool dfu
and i’m able to execute just fine [THANK YOU!] but exhibits same behavior, it’s stays in
"Putting device into DFU mode…
and stays there
Any idea what to do next? how do i get it back to continue?
it’s supposed to continue with
Erasing… done
Flashing… done
Verifying… done
What happened when you tried enter_dfu_mode()?
It should disconnect (and reappear as a DFU device) you then need to quit odrivetool and run odrivetool dfu
yes, I did and I get the same behavior, that is, it gets stuck in
"Putting device into DFU mode…
forever. I did run dmesg afterward and this is what i get…
After that, only way to reconnect to the odrive is by power cycling it.
Do you suspect a hardware problem? See this link from another user…
2 ODrives out of 3 i’ve used have exhibited hardware problems, is that typical for these units?
Very odd. 
If you have used enter_dfu_mode() and it disconnects (and you see STM32 Bootloader in dmesg as I can see that you do) then odrivetool dfu should NOT say “putting device into DFU mode” since there is no ODrive device there, only a STM32 Bootloader (i.e. DFU) device.
Instead, it should say “found one ODrive device already in DFU mode, do you want to flash it? warning, this will reset config values to default”
From your dmesg, it looks as though the hardware is working. Something is wrong in odrivetool.
Try running the tool from the GitHub repo again, make sure that you see “STM32 Bootloader” in dmesg beforehand.
(failed to set dtr/rts is normal, and the other warnings are related to that, i think)
Also, please check that ModemManager is not running! It has a habit of screwing up anything that uses a virtual serial port (eg ODrive)
1 Like
OK, this is what happens. I start ODrive and it connects as odrv0, we’re good. Then, I run odrv0.enter_dfu() and i get a message
Oh no odrv0 disappeared
I let it for a few seconds and i get
Downloading json data from Odrive…
Reconnected to Odrive blah blah
I quit() out and then run
Odrivetool dfu
and I get the behavior shown above, as shown by my dmesg
Ok, that is wrong. It should stay in DFU mode and not reconnect. Possibly some other process is waking it out of DFU mode (e.g. ModemManager as I mentioned above)
That’s to be expected, probably. But I don’t understand why the DFU bootloader is exiting and going back to the main porogram. As I say maybe some other program on your PC (like ModemManager) is trying to talk to it, sending garbage it doesn’t understand, and causes a reset.
Try this:
flip the ‘DFU’ switch on the board, and disconnect power. Leave USB plugged in.
run ‘odrivetool dfu’
When you get a ‘waiting for odrive’ prompt, turn on power.
Hopefully that will allow odrivetool to ‘get there first’ before the DFU bootloader exits.
Once programmed, flip back to ‘RUN’ mode and reset power
1 Like
Got it! You were right on the money when you said some other program was trying to talk to the odrive. I follow the same ‘new’ procedure, that is, to set odrive in dfu mode from the odrive shell BUT ON MY MAC and that worked and was able to do the firmware update. There’s probably other program trying to access the odrive on ubuntu as i killed ModemManager. THANK YOU THANK YOU THANK YOU!
2 Likes
ModemManager respawns automatically when you kill it, thanks to SystemD.
Your best bet is to use systemctl disable ModemManager or better yet, apt-get remove modemmanager 
2 Likes
I had similar problems with the firmware update. At the end I was able to update the firmware with the ST-link-V2. You can find the tutorial on the odrive guide. To make it work I did not follow the tutorial in every point, if I remember correctly I had to connect the Vcc between the St-link and the Odrive. I’m not shure of it, so verify my words before trying this, I don’t want to be the cause of a hardware failure. Hope this can help you.
1 Like