Firmware 0.5.2 Release Thread

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.

21

I got the same problem, I just downgraded to 0.5.1 again, because I don’t have the time atm to figure out what the problem is exactly. 0.5.1 works without problems.

22

Experiencing UART/ASCII issues (over GPIO1/2) after upgrading one of my odrives to 0.5.2:

Not entirely sure what’s happening but it seems like UART on the new firmware is more susceptible to electrical noise perhaps.

UART connection drops when odrive.axis is set to closed loop control state.
Even if only my other odrive (running 0.5.1) is set to closed loop control - the odrive running 0.5.2 stops sending data over UART.
The odrive (running 0.5.2) must be reboot or power cycled before the UART/ASCII protocol starts working again - ie just removing the electrical noise doesn’t seem to correct the issue.

Note: not using checksum in ascii protocol.

I noticed the release page states: " * ASCII and the Native Protocol do not run at the same time on a UART interface. See odrv0.config.uart0_protocol and the STREAM_PROTOCOL_TYPE enums for details." - not sure if that’s relevant or not.

Unfortunately I cannot proceed with my project with 0.5.2 until this issue is resolved - so rolling back to 0.5.1.

Anyone else experiencing anything like this?

EDIT0: problem persists if reconfigured using UART1 with GPIO3/4.

23

Awesome, updates are always welcome.

But for some reason my settings can’t be saved?

odrv0.save_configuration()

Returns a False, why and how?

Another question:
How do I change

odrv0.config.gpio1_pwm_mapping.endpoint = odrv0.axis0.controller._remote_attributes[‘input_pos’]

To the new 0.5.2, is this correct?

odrv0.config.gpio1_pwm_mapping.endpoint = odrv0.axis0.controller._input_pos_property

24

Was the motor armed when you tried this? If yes, this is expected. If not, do you have an STLink debugger? With that you could investigate which of these three functions fails, and where.

Yes.

1 Like