Unresponsive Board

Support
1

I have a V3.6 56v board that has been working perfectly and suddenly became unresponsive.
I have been testing controlling two motors via Arduino and without any changes to the configuration or wiring, the Odrive stopped responding to commands.

Upon rebooting the board I found that the board is not starting normally as the two-axis with end-stops are not homing on startup as they are set up.
In addition, the board is not found by the python drive tool app nor is it showing up as a device in my Windows 11 device manager as a connected device.

The power light is on and I have tested all ground and power pins on the board to find they are providing the correct voltages.

Nothing appears to be damaged, hot, or smells weird via inspection of the board. My application up to this point has not been pushing the board’s capabilities at all and I have in fact been underdriving the controller with 24v and nothing has ever even gotten warm during operation.

I have disconnected everything from the board aside from the brake resistor without any change to the situation…

What can I try?

2

I tried switching into DFU mode to see if I could at least connect to the board in that context and the odrive did show up as a STM32 Bootloader device in Zadig. I loaded the libusb-win32 driver for it but a connection attempt with odrivetools dfu fails as follows:

ODrive control utility v0.6.0.dev67
Waiting for ODrive...
found device but could not check serial number (retrying in 1s)
found device but could not check serial number (retrying in 1s)
found device but could not check serial number (retrying in 1s)
---------------------------------------------------------------------------
Exception                                 Traceback (most recent call last)
~\anaconda3\Scripts\odrivetool in <module>
    155                 # https://docs.python.org/3/library/asyncio-platforms.html#asyncio-windows-subprocess
    156                 asyncio.set_event_loop_policy(asyncio.WindowsProactorEventLoopPolicy())
--> 157             asyncio.run(odrive.dfu.launch_dfu(
    158                 serial_number=args.serial_number,
    159                 path=args.path,

~\anaconda3\lib\asyncio\runners.py in run(main, debug)
     42         if debug is not None:
     43             loop.set_debug(debug)
---> 44         return loop.run_until_complete(main)
     45     finally:
     46         try:

~\anaconda3\lib\asyncio\base_events.py in run_until_complete(self, future)
    640             raise RuntimeError('Event loop stopped before Future completed.')
    641
--> 642         return future.result()
    643
    644     def stop(self):

~\anaconda3\lib\site-packages\odrive\dfu.py in launch_dfu(serial_number, path, channel, logger)
    301         if path is None:
    302             if isinstance(device, ODriveInDfuMode):
--> 303                 device.init(logger, ask=True)
    304                 product = device.product
    305             else:

~\anaconda3\lib\site-packages\odrive\dfu.py in init(self, logger, ask)
     40             return
     41         self._initialized = True
---> 42         DfuDevice.init(self)
     43
     44         is_odrive3 = self.memories['OTP Memory']['sectors'][0]['addr'] == 0x1fff7800

~\anaconda3\lib\site-packages\odrive\dfuse\DfuDevice.py in init(self)
    101             intf_name = usb.util.get_string(self._dev, intf.iInterface)
    102             if intf_name.count('/') != 2:
--> 103                 raise Exception(f"invalid interface name for interface {intf.iInterface}: {intf_name}")
    104             label, baseaddr, layout = intf_name.split('/')
    105             baseaddr = int(baseaddr, 0) # convert hex to decimal

Exception: invalid interface name for interface 4: Љ
3

If you have a raspberry pi or other linux-based computer, you could try using DFU from there.
libusb in Windows is horribly, horribly unreliable.

Also, try unplugging other USB devices. From the text above, it looks as if it could be some other USB device that is crashing the script.

1 Like
4

If towen’s advice doesn’t work, check out odrivetool — ODrive Documentation 0.0 documentation

1 Like
5

Thanks for the help @towen and @Wetmelon. That did the trick and I’m back in business!

The exact process that worked:

  1. Forced into DFU Mode with dip switch
  2. Associated the libusb-win32 driver to the STM Bootloader connection in Zadig.
  3. Connected to the STM bootloader with the STM32 CubeProgrammer app listed as alternatives in Wetmellon’s Documentation Link above
  4. Selected my downloaded firmware in the Erasing & Programing tab
  5. Programed
  6. Forced back into Run mode with dip switch
  7. Rebooted and connected with odrivetool
  8. Bob’s your uncle!
Connected to ODrive 366938923131 as odrv0
In [1]: odrv0.vbus_voltage
Out[1]: 23.8798828125

Thanks much for your help!

Anything you can think of that may have forced my board into an unresponsive state while being tasked by an Arduino in the first place so that I may avoid it?

1 Like
6

I have seen this before, but it’s a really hard bug to reproduce. For me, it was when using “startup_closed_loop_control=True” and with a relatively high bus voltage, I would sometimes find that the ODrive erased/corrupted its own flash on poweroff. But it doesn’t do it anymore for me.

1 Like
7

Thanks for the insight. Whether it be a rare edge case, bad luck, or something to do with the particular sequence or timing of the commands, I’m adding some SD card event logging to my app. If this becomes a reoccurring issue and a pattern emerges I’ll be sure to post it back to the group.
– Cheers!