Firmware upgrade to 0.5.2usb disappear, brush 0.5.1 firmware completely normal, solve the problem,Ask for help。
Seems to be a bug in 0.5.2. We plan to release a bugfix for this at 0.5.3 so please wait. If you get any errors please tell us what errors you get.
Thank you very much
When will version 0.5.3 be upgraded?
Hi @LEE-8888, we’ve been focused on testing the upcoming generation of ODrive hardware. 0.5.3 seems to be stable, but we simply haven’t had time to test it sufficiently to feel good about releasing yet. You can help us by testing it if you’d like
Could you send me a copy of version 0.5.3, I would like to participate in the test.
e-mail:1021462467@qq.com
thanks
Could you send me a copy of version 0.5.3, I would like to participate in the test.
e-mail:79456555@qq.com
thanks
Hi,
you can go to the ODrive github page, download the git repository, checkout the 0.5.3 branch and compile the firmware yourself.
Did that, exactly the same result as with 0.5.2.
Also, going through the commits there doesn’t seem to be anything specifically addressing the issue? I can upload a 0.5.3 binary if anyone’s interested. The 0.5.3 bin does downgrade to 0.5.1 ok through dfu-util. Command used to flash either image:
dfu-util -v -w -R -a 0 -d 0483:df11 -s 0x08000000:leave -D ODriveFirmware.bin
@Wetmelon Do you / does ODrive have any idea why 0.5.2 won’t run?
I bisected the firmware source and found the commit causing the issue:
This commit adds a ‘feature’ not mentioned in any advertising: DRM (even named as such). While not named as such, the internal version checks indeed cause the board to hang (on purpose, with an infinite loop) silently if no correct information is found.
In my case I didn’t even know I had an unofficial board so that was fun to find out this way after wasting a lot of time. I don’t mind that ODrive implemented this feature, it’s fair to protect investments, but the way it’s done / communicated here is a big red flag for consideration for adoption in commercial projects. It would be great if ODrive could clarify their stance on this.
Commenting out the DRM / OTP version checks and the silent infinite loop hanging boards will indeed make 0.5.2 work just fine.
Did you buy the board from odriverobotics.com?
We didn’t intend for this feature to be DRM (in the sense of stopping non-official boards), it’s intended to prevent the wrong firmware from running on a controller. We talked about either removing that check, or at least making it fail loudly (do no initialize hardware, but let odrivetool check for a “BAD OTP” error or something like that).
The “NO_DRM” flag is actually something else unrelated that got pulled into the commit (you can see it’s not being used)
Did you buy the board from odriverobotics.com?
I got it from a local store, they sold it as original ODrive, for approx the same price as the site. Already spoke to them about it. They claim their supplier offered these to them as legit. Hard to verify, but normally their products are original.
Even with the official boards a proper notification would be a massive improvement and could be as simple as inserting one before that infinite loop. I think a “non-supported / 3rd party board” notification will also help your cause, as it’ll create some awareness.
Just a side-note about v4: If you have a couple of spare GPIOs you can encode the board version in the PCB itself by using those as tristate. Get 3^PINS states. Tie pin to ground == 0, tie pin to VIO == 1 and unconnected (assert using internal pull up/down) == 2. Will give you some more IC flexibility.
Can you please share what lines you commented out?
I have also bought odrives, believing they were real, and therefore have problems with version 0.5.2.
I didn’t post that on purpose, because I felt that was a little inappropriate to do here. If someone from ODrive states they don’t mind I’d be happy to post a patch for 0.5.2 which disables the checks.
Ok, i understand. Maybe you send me a mail: on wilhelmbe@gmail.com?
I have new 3 geniune odrive boards on the way, but would be really great to get on with the project, and to still be able to use the one i already have.
The branch fw-v0.5.3
already skips the hardware version check if the OTP is empty.
That’s interesting. I tried the 0.5.3 branch first and it didn’t work. Same result as with 0.5.2. Didn’t bisect or check the code there, as I figured the problematic change was between 0.5.1 and 0.5.2.
Ok maybe your device has the OTP written, but with content that doesn’t comply to what the firmware expects. You can check the contents with x/16bx 0x1FFF7800U
in GDB (make gdb
).