V0.5.2 Release Upgrade Woes

So like a moron I tried to upgrade the board (v3.6) firmware as I saw there was a new release before reading the documentation and upgrading the odrivetool first. Now the ODrive won’t connect to the python terminal. When upgrading the firmware I got this error:

ODrive control utility v0.5.1.post0
Waiting for ODrive…
Found ODrive 206539964D4D (v3.6-24V) with firmware v0.5.1-dev
Checking online for newest firmware… found v0.5.2
Downloading firmware v0.5.2…
Saving configuration to C:\Users\CONNOR~1\AppData\Local\Temp\odrive-config-206539964D4D.json…
Configuration saved.
Putting device 206539964D4D into DFU mode…
Erasing… done
Flashing… (sector 0/7)

RuntimeError Traceback (most recent call last)
~\Anaconda3\Scripts\odrivetool in
141 print_version()
142 import odrive.dfu
→ 143 odrive.dfu.launch_dfu(args, logger, app_shutdown_token)
145 elif args.command == ‘liveplotter’:

~\Anaconda3\lib\site-packages\odrive\dfu.py in launch_dfu(args, logger, cancellation_token)
463 firmware = FirmwareFromFile(args.file) if args.file else None
→ 465 update_device(device, firmware, logger, cancellation_token)

~\Anaconda3\lib\site-packages\odrive\dfu.py in update_device(device, firmware, logger, cancellation_token)
391 for i, (sector, data) in enumerate(touched_sectors):
392 print(“Flashing… (sector {}/{}) \r”.format(i, len(touched_sectors)), end=’’, flush=True)
→ 393 dfudev.write_sector(sector, data)
394 print(‘Flashing… done \r’, end=’’, flush=True)
395 finally:

~\Anaconda3\lib\site-packages\odrive\dfuse\DfuDevice.py in write_sector(self, sector, data)
199 status = self.wait_while_state(DfuState.DFU_DOWNLOAD_BUSY)
200 if status[1] != DfuState.DFU_DOWNLOAD_IDLE:
→ 201 raise RuntimeError(“An error occured. Device Status: {!r}”.format(status))
203 def read_sector(self, sector):

RuntimeError: An error occured. Device Status: (0, 2, 0, 0)

What do I need to do to get it back working?

ok, so your problem was that you didn’t also upgrade your odrivetool version.
Personally, I shun pip and only use the odrivetool from the git repo, so it always matches my firmware version.

To get it working again, you need to flip the ‘DFU’ switch to force the board to start up in bootloader mode.
That /should/ mean that odrivetool will detect it.
Obviously you should put it back to ‘run’ mode afterwards.

Then once it’s working again, run odrivetool restore-config C:\Users\CONNOR~1\AppData\Local\Temp\odrive-config-206539964D4D.json
to get your config back.

(TBH, you might not want to keep your old config as some of it will be incompatible with the new firmware)


I did all that and used the STM32CubeProgrammer to re-install the firmware as the anaconda terminal was not recognizing the board.

I used the 0.5.2 firmware .hex file from the github and flashed that to the board. It was successful.

However now when I got to check the firmware revision - odrv0.fw_version_revision - it comes up as 1 instead of 2. I still cannot use the terminal to dfu as it still throws errors (even after having upgrading the odrivetool). I get the message to change the driver using zadig to libusb-win32, which I do and then it fails.

Is there any chance you have access to a Linux environment? (e.g. Raspberry Pi)
USB on Windows is just so shit :frowning:

No idea about the FW revision, but my guess is it’s probably correct. @Wetmelon might know more.

yeah, our problem. We released it before we made the 0.5.2 tag, so it still reads “0.5.1-dev”

@Wetmelon ah ok good to know

has there been a problem with the new firmware about save_configuration()? when I do it the terminal returns a “False” instead of actually saving the config. I have to do odrv0.axis0.requested_state = AXIS_STATE_ENCODER_INDEX_SEARCH and then it will work (doesn’t work for axis1).

Nope, that’s on purpose. The axes have to be in IDLE.