Exploded ODrive Resurrection (SUCCESS, Recognized as not Genuine)

Some time ago, when working on a university project, a friend blew up my ODrive V3.5 by dropping a screwdriver on it. (BIG SAD) A replacement V3.6 was purchased.

We viewed it under a thermal camera, and found that only the MCU was attempting to start a nuclear fusion reaction, everything was relatively chill.

*Before power-on, ignore reflective surfaces, also apologies for the butchered resolution caused by the capture software

*After power-on, this is with a NEW MCU soldered, the fried one was too hot to photograph before it burns a hole in the board

There was a resistor and an IC that heated up slightly which were identified as the VBUS sampling resistor R6 and the CAN BUS transceiver IC U1, so that is to be expected I guess. This information can hopefully help others attempting rescue or debugging.

We hoped that only the MCU failed but obviously others could have failed open, but the ODrive isn’t unwieldly complicated so we hoped to repair it regardless of how many components failed.
We first desoldered the blown micro, and measured all the rail voltages that confirmed to be working:
there are three rails, the first one is the 5 V rail which is generated by the integrated buck controller of U4, the bridge driver of axis0; the second and third are digital and analog 3.3 V rails, which are generated by U3 and U8 LDOs, respectively.
This is looking good so far!
We ordered an STM32F405RGT6 from digikey.ca for 15 bucks, and reflowed it using a cheap hot air station. It sadly did not work, more specifically it always failed to connect to the ST-LINK, but we only had one night to spend on repairing it so it was left as that.

Attempt #2
Fast-forward two years…
Now doing graduate studies, I attempted to repair it again, and it is a success!!
The first step was to identify that the SWC pin (pin 49, PA14) was shorted to pin 50 (PA15)… After redoing the solder job on those pins and plugging it in, it was instantly picked up by STM32 cube programmer! Firmware 0.5.4 was downloaded and flashed onto it with-in seconds, and verify was also successful!

It still would NOT be detected as an USB device, let alone being picked-up by odrivetool, the same goes with it booted up in DFU mode, so something is suspicious. I suspected there are maybe solder bridges or bad joints, so I tinned all the pins of the MCU and wicked them clean, some IPA wiping and bam! It connected!!!

I still need to fully test it but so far it seems promising? I will also update with actual tests if it turns out to have any failures.
So yeah, a relatively uneventful repair but hopefully someone else going through this may find it helpful. There are a few noteworthy oddities though, and I may need your help on understanding this…

Oddity #1
The memory address of the firmware extends to 0x0804BE64, yet the MCU memory address only extends to 0x0804BE30. Why is that? and are the extra bytes important? Would they not be written onto other components of the MCU?

Oddity #2
As you may have noticed from one of the screenshots, odrivetool reports this ODrive as not being genuine. Why is that? I know that STM32s have globally unique serial numbers, but does odrivetool check against an online database of the serial number of all sold ODrives? Is there a way I may get rid of this? Having to call them dev0 instead of odrv0 is… not as cool :smile:

Ending notes
These are my ODrives side-by-side, I might be a fanboy but I’m proud of it; I have recommend them to countless engineering students and professors.

Note that the V3.5 has tinned via pads while the V3.6 does not, why was the solder paste removed in V3.6? Is it for looks? Just curious.

An advice, PRINT AN ENCLOSURE, or CONFORMAL COAT your ODrive; I am doing exactly both.

I love the ODrive, and it is sad to see that they have turned into non-open-hardware; I do understand the reasoning behind it, it is evil to plainly clone the entire circuit design and sell it at a more competitive price, but at the same time this decision could greatly hinder custom adaptations. I have mixed feeling about this move.

The ODrive have been through a lot with me, magnetic levitation (electrodynamic suspension using eddy currents) in first year, high positional accuracy trash robot car in second year, and now it is going inside an SEM for a professor’s project :slight_smile:

I hope to see the ODrive grow to extreme success, and maybe I could help contribute what I know, it would be amazing to see modern control theory implemented such as state-spaced controllers, linear quadratic regulators, kalman filters, and even model predictive control. I’ve grown out of PID controllers ;).

A huge thanks to Oskar and the ODrive community!


Data about board revision and voltage stored in STM32 OTP Memory. You must program OTP in order to remove this message. But be careful, because OTP == One Time Programmable.

Yes, now it’s “just another expensive closed-source BLDC Driver”. But v3.6 is already great, and it has everything we need for almost any project. And there’s also opensource MIT Cheetah controller and some other projects.


Nice writeup! I’m glad you got it working again. Thanks for the long time support!

Well the Flash is 1MB so the address should go up to 0x08100000. I guess whichever memory inspector you have is giving you partial results for the MCU flash. The hex file can of course just end wherever.

Sorry about that we don’t really have a good way to fix that in the field. You’ll be happy to know that the new generation should support repairs nicer. Although with the full enclosure hopefully it shouldn’t be needed :wink:

Actually the design still says to put solder paste there, but the fab we are using probably removed it in their CAM pass. I don’t really know why but I also think the conductivity boost is very minor so I decided to not worry about it.

We actually plan to launch a licencing program where you can run ODrive firmware on your own design using the S1 or Pro as a reference design to base your custom board off. We haven’t ironed out the details yet, but if you desperately need something soon please reach out on Discord or by email and we can talk.

This is actually all on our roadmap. MPC maybe on a higher level, not individual motor level. But in general yes all those.