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.
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
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)
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…
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)
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
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!
