Over the past several weeks, I’ve been working to restore functionality to my ODrive S1 (v0.6.11) after a series of firmware and hardware setbacks. Here’s a detailed breakdown of what I’ve tried, what changed, and where things stand:
Original Setup
• ODrive S1 was successfully controlling an Open QDD actuator.
• System was powered via a Raspberry Pi, running at 13V.
• Everything worked initially—motor control, calibration, and USB communication.
Hardware Failure & Voltage Adjustment
• After a Raspberry Pi failure (likely fried), the ODrive began showing undervoltage errors.
• Switched power supply from 13V to 24V, which resolved the undervoltage fault.
• However, calibration started failing with errors related to encoder pole pairs and motor parameters—even though the actuator hadn’t changed.
Firmware Flashing Attempts
• Tried flashing firmware via both CLI (odrivetool dfu) and Web GUI.
• GUI stalled mid-transfer and falsely reported success after reload.
• CLI often returned errors like:• SystemExit
• AssertionError (when using new-dfu)
• 'anonymous_interface' (after partial firmware boots)
• Board would sometimes boot with a solid blue LED, but not expose full API.
USB Driver Troubleshooting with Zadig
• Used Zadig to install the WinUSB driver for “DFU in FS Mode.”
• This allowed Python and CLI tools to consistently recognize the board.
• However, Web GUI stopped detecting the board after the driver change.
• Reinstalling the default driver restored GUI visibility, but broke CLI flashing again.
• So far, I’ve been unable to find a driver configuration that allows both GUI and CLI flashing to work reliably.
Firmware Behavior
• Board sometimes connects via odrivetool, but returns 'anonymous_interface', meaning firmware is present but not exposing the full API.
• Attempts to flash custom .hex files from STM32CubeIDE fail with AssertionError due to missing manifest.
• Legacy dfu command works better, but doesn’t yield a functional firmware state.
• DFU mode (purple LED flashing) no longer activates, suggesting bootloader may be corrupted or overwritten.
Remaining Questions
• Is there a way to restore DFU mode without using an ST-Link programmer?
• Can I modify my custom .hex build to include the required manifest for new-dfu?
• Why would encoder calibration suddenly fail after a voltage change, even with the same actuator?
• Is there a known fix for boards that boot into firmware but expose only an anonymous interface?
Any help or insight would be appreciated. I’ve documented each step thoroughly and would love to hear from anyone who’s recovered from similar issues or has experience with Open QDD integration.
Thanks in advance!