Unable to update firmware from v0.4.12-dev to v0.5.1

I got two new ODrive boards a while back and one came with an older version of the firmware [v0.4.12-dev]. I’m trying to update it to v0.5.1 using the dfu utility (i.e., odrivetool dfu from ubuntu command line), but it goes thru the right sequence but gets stuck on:

         Putting device <my device number> into DFU mode...

…and it stays there forever. The docs says to try to unplug the usb cable, tried that as well with no avail. I also have an ST-LINK V2 I ordered from ODrive as well, but it fails to make a connection and I’m sure it’s properly wired up. I also tried updating using my mac with the dfu utility as well as with the ST-LINK, again with no success. I get exact same behavior on both environments. Anyone has any insights on what’s going on? Is it a hardware problem? The board seems to go thru the calibration sequence just fine, but i’m trying to execute some code i wrote on the other board and some commands are obsolete, so need to update it to v0.5.1 to be at par with the other Odrive board i have. Any help, suggestions are very welcomed. Thank you.

Could be a permissions issue under Linux (ie you have permission to use the CDC device but not the DFU device). Have you tried with sudo?

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. :thinking:
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)

if i quit() before it reconnects, i get the following traceback…

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