Backstory
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.
- R6 heating up due to the power dissipation, @ VBUS ~= 24 V
- U1 heating up, no comments on that
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 
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 
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!
