Firmware 0.5.2 Release Thread

1

Firmware v0.5.2 is now officially released! A matching version of odrivetool has also been published.

You can upgrade odrivetool by running pip install --upgrade odrive. After that, you can upgrade the firmware on your ODrive with odrivetool dfu.

This release greatly improved free processing time. Running dual-axis RC PWM no longer causes DEADLINE_MISS errors and the maximum step rate for step/dir has been increased. You can find the full list of changes on the release page here.

Happy ODriving!

EDIT: The release verison strings in this firmware are wrong. It will read 0.5.1-dev instead of 0.5.2. This will be corrected in 0.5.3.

EDIT 2: This is now superseded by Firmware 0.5.3

1 Like
2
3

HI,

find_all(), or find_any(find_multiple=…) doesn’t exist in new odrivetool. How can one find multiple devices?

as well as _json_data and _remote_attributes doesn’t exist. Any suggestions how to iterate through available configurations?

4

Hi.
I don’t know it’s just me or it’s a real problem with DRV8301 in firmware version 0.5.2.
It’s normal when the motors are not connected to ODrive. But [MOTOR_ERROR_DRV_FAULT] error occurs when the motors are connected. The error code is In [1]: odrv0.axis1.last_drv_fault Out[1]: 8390655

And the odrivetool seems to have some connection issues. So I have to use ODrive control utility v0.5.1 instead. v0.5.2 gives me this:
e[91;1m20:37:05.274147100 [USB] Could not open USB device: -3e[0m very often.

It would be so nice to have your advice.

5

@tinker_inc To find all ODrives you can look at the implementation of find_any as a reference. You’d do something like this:

async def discovered_object(obj):
    # do something with obj

with domain as fibre.Domain(path)
    discovery = domain.run_discovery(discovered_object)
    # do something until the discovery is supposed to stop
    discovery.stop()

To iterate over property members of an object you can look at how odrivetool fetches a configuration snapshot: ODrive/configuration.py at master · odriverobotics/ODrive · GitHub

1 Like
6

Hey,
I´m on 0.5.1 atm and when i upgrade to 0.5.2 with odrivetool DFU i get the error 0.0.2.0 and the odrive isn´t recognised by windows anymore. If i put it into DFU mode manually and flash back the 0.5.1 firmare with the ST cube Programm it works fine again. If i flash the 0.5.2 firmware with the ST tool i dont get any errors and then I put the odrive back out of DFU mode and again its not recognised by windows anymore.

Can sombody tell me what am i doing wrong?
Thanks for the help.

7

Can you try odrv.erase_configuration() while still on 0.5.1 and then upgrade with a cleared configuration?

8

just tried it, no change in behavior i tried both odrivetool dfu and the STM32Cubeprogrammer software. Also i tried 0.5.2 rc2 few minutes ago and no changes there either.

9

I get the same issue too. After upgraded to 0.5.2(V3.6-56V), usb can’t be recognized any more.
Thanks for any help.

10

if you want to get back to 0.5.1, download this https://github.com/odriverobotics/ODrive/releases/download/fw-v0.5.1/ODriveFirmware_v3.6-56V.hex
and the folow the steps here ODrive Tool | ODrive
where the method for STM32CubeProgrammer is listed.

1 Like
11

One thing that i think is happening is that the new 0.5.2 firmware is checking for the board version in otp memeroy of stm32 and thats fucking with things. can you compile a firmware version 0.5.2 for odrive 3.6 56V for me that skips the firmware check?

i dont want to set up everything that is needed to compile the odrive FW myself.

12

Ah yes it’s possible that this check is causing issues. What indications do you have that point towards this?

We have a procedure in place to flash all boards with both firmware and OTP before shipping them but it’s well possible that some boards have slipped through with an invalid OTP. So if you think this is what’s causing the boot issue then that’s a hardware bug. In this case please email info@odriverobotics.com with your order number to arrange a replacement of your board.

13

I don’t really know. It’s the only thing that came to my mind, because I read it somewhere on here unrelated.

14

Thank you for the answer. I managed to get the property members. Would you also know a way to find out if property is read or read/write?
Thanks

15

Hi vogel25, as you say, OTP version checking cause the issue. Thanks.

16

If the property object has a member function exchange then it’s read-write, otherwise it’s read-only. You can check this for example with hasattr(my_property, "exchange").

17

Have you compiled a version without the check, I’m currently in the process of it, let me know if you need it.

18

Yes, I have compiled a verion without the check.

19

I think I have it fixed, it seems to work now, with my own compiled firmware.

20

Hi vogel25, I got another issue, after doing some configuraion and save_configuration(), it takes no effect.
Thanks for the help.