56V v3.6 odrive will not connect to USB in run, cannot flash

I think I bricked my 56V v3.6 odrive.

Symptoms:

  • no longer connects to USB in run mode
  • DFU usb connects, but cannot flash
  • ST link cannot connect to target

Repro steps:

odrv0.vbus_voltage > ~14.3
odrv0.axis0.motor.config.calibration_current=5
odrv0.axis0.motor.config.pole_pairs=21
odrv0.axis0.motor.config.motor_type=MOTOR_TYPE_HIGH_CURRENT
odrv0.axis0.encoder.config.cpr=8192
odrv0.save_configuration()
odrv0.reboot()
odrv0.axis0.requested_state = AXIS_STATE_FULL_CALIBRATION_SEQUENCE (completes left right motion)

Things start to go bad here:
odrv0.axis0.requested_state = AXIS_STATE_CLOSED_LOOP_CONTROL (state change error)
Reboot:

odrv0.axis0.requested_state = AXIS_STATE_ENCODER_OFFSET_CALIBRATION
dump_errors(odrv0): https://discourse.odriverobotics.com/t/motor-failed-current-unstable/3194

Reboot:

odrv0.axis0.requested_state = AXIS_STATE_FULL_CALIBRATION_SEQUENCE (completes left right motion)
dump_errors(odrv0): (all good)

odrv0.axis0.encoder.config.use_index=True
odrv0.axis0.requested_state = AXIS_STATE_ENCODER_INDEX_SEARCH
dump_errors(odrv0): https://discourse.odriverobotics.com/t/motor-failed-current-unstable/3194

Reboot:
odrv0.axis0.motor.config.calibration_current=10
odrv0.axis0.requested_state = AXIS_STATE_FULL_CALIBRATION_SEQUENCE (completes left right motion)
dump_errors(odrv0): (all good)
odrv0.save_configuration()
odrv0.reboot()

Never reconnected again

DFU link:
Shows up under Zadig as STLink32 bootloader:

odrivetool -v dfu
ODrive control utility v0.4.11
Waiting for ODrive...

STLink flash:

openocd  -f interface/stlink-v2.cfg -f target/stm32f4x.cfg -c init -c "reset halt" -c "flash write_image erase C:\Users\matt\Downloads\ODriveFirmware_v3.6-56V.elf" -c "reset run" -c exit
xPack OpenOCD, 64-bit Open On-Chip Debugger 0.10.0+dev (2019-07-17-11:28)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
WARNING: interface/stlink-v2.cfg is deprecated, please switch to interface/stlink.cfg
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
Info : clock speed 2000 kHz
Info : STLINK V2J17S4 (API v2) VID:PID 0483:3748
Info : Target voltage: 3.263872
Error: init mode failed (unable to connect to the target)

I tried rebooting the computer, tried every usb port, tried multiple usb cables.

In DFU mode the bootloader will connect to usb, but it cannot flash the chip, and run mode will not connect to usb, and STLink will not connect to target.

Update:
I hooked everything up again and it seems the Odrive board can only connect to USB while the STLink is attached. When i attach both the Odrive usb, and the STLink, the odrive usb interface appear in zadig. If i unplug the STLink, the odrive usb interfaces disappear and I can no longer communicate with the board via odrivetool.

It seems as though the board is being powered through STLink?

The good news, with STLink connected, i’m able to connect to the board and I was able to finish calibration by increasing my current_tol. The motor is correctly working in closed loop position control.

However, I cannot use the Odrive unless the STLink is connected? Any ideas?

Yes, the 5v line is powered by the STLink if you plug it in.

What resistance do you measure between +BATT and -BATT with everything disconnected? If you turn the power on, what voltage do you see on the 5V line?

6k ohm
5.14v

Now it’s working without using the stlink.

If i see that it’s not connecting again, i’ll check those measurements again.

It seems like we had the same problem. It was not possible to connect or flash the ODrive-Boards via USB until we disconnected them from the main power supply and powered the Boards via STLink instead.

You may have a noisy power supply or a ground loop in that case. Please check with an oscilloscope if you have one. You can also upgrade to a shorter or higher quality USB cable

1 Like

For a while we could use our board without any problem. But after some time the board showed strange behavior. Sometimes it did not react to new input values at all, sometimes the motors started vibrating. We tried flashing the firmware (0.5.1) again. Now the connectivity issues are back again.

Thank you for your ideas, Wetmelon! We checked the power supply, changed the USB cable and don’t think that we have a ground loop. At the moment it is possible to flash the board in DFU mode but it doesn’t reappear back in RUN mode. Any other suggestions?

It’s ODrive v3.6 56V. And there is another board connected in the same way without any problems.

If the ST-Link is still connected, the board may be held in RESET?

If you have access to a Linux computer e.g. Raspberry Pi, check the output of dmesg -w when you plug the USB in.
If you’re on Windows (God help you) you might need to use some tool (Zadig?) to change USB driver from DFU to libusb-win32.

1 Like

Thanks towen!
At the moment we are only using the 5V and GND of the STLink.

dmesg -w gives the following output:

[  400.482657] usb 1-2: new full-speed USB device number 8 using xhci_hcd
[  400.624800] usb 1-2: New USB device found, idVendor=1209, idProduct=0d32, bcdDevice= 3.00
[  400.624809] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  400.624814] usb 1-2: Product: ODrive 3.6 CDC Interface
[  400.624818] usb 1-2: Manufacturer: ODrive Robotics
[  400.624821] usb 1-2: SerialNumber: 3351314C3536

starting odrivetool in verbose mode gives:

ConfigurationValue 1
	InterfaceNumber 0,0
		EndpointAddress 130
	InterfaceNumber 1,0
		EndpointAddress 1
		EndpointAddress 129
	InterfaceNumber 2,0
		EndpointAddress 3
		EndpointAddress 131
Kernel Driver was not attached
EndpointAddress for writing 3
EndpointAddress for reading 131
Connecting to device on USB device bus 1 device 9

But even after minutes of waiting nothing happens.

did you run sudo odrivetool udev-setup ?

also as a sanity check you can try running odrivetool as root. if that works then it’s a udev issue

Unfortunately running sudo odrivetool udev-setup and sudo odrivetool didn’t help. Any other idea?

@qwert what version of ODrivetool is this? It’s probable that you have an old version e.g. installed by pip. Maybe it has a bug or is incompatible with the newer firmware?
Can you try uninstalling your odrivetool from however you installed it, and instead run
python3 tools/odrivetool
from the Git repository?

You can also try sudo python3 tools/odrivetool udev-setup etc.

Unfortunately even with running odrivetool from the devel-branch it doesn’t work.
At a second board everything is fine.

That is odd. Are both boards running the same firmware?

Thank you so much for your effort, towen! It seems to finally work now.
After disconnecting the CAN bus cables the board somehow appeared in odrivetool.