Odrivetool stopped connecting (Windows), Stlink won't connect either

I’m encountering some strange behavior on my previously working odrive 3.5-48V:
I flashed the board previously using openocd and an ST-link I had, and it worked successfully. I was able to control both of my hoverboard motors.

Today I started up odrivetool (on widows) and it connected normally. One of my motors may have had a bad connection do to some soldering, so I checked the connections and reran odrivetool. Since that first connection this morning, I have been unsuccessful at connecting to my odrive. I figured reflashing the firmware might yield positive results, so I switched from windows to ubuntu 16.04 and ran an identical openocd command to the one that previously successfully flashed my board. (In the correct directory).
openocd -f interface/stlink-v2.cfg -f target/stm32f4x.cfg -c init -c reset\ halt -c flash\ write_image\ erase\ ODriveFirmware_v3.4-24V.elf -c reset\ run -c exit

However, there seems to be an issue there as well, as openocd gives me the output of:

Open On-Chip Debugger 0.9.0 (2018-01-24-01:05)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
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
adapter speed: 2000 kHz
adapter_nsrst_delay: 100
none separate
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : clock speed 1800 kHz
Info : STLINK v2 JTAG v17 API v2 SWIM v4 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 3.224753
Error: init mode failed (unable to connect to the target)
in procedure 'init' 
in procedure 'ocd_bouncer'

My stlink v2 has its indicator light on and shows up in an lsusb, and I’ve checked the connections. My odrive has its green led on, but I can’t seem to get anything out of it to indicate it isn’t fried or something. Nothing happened between when it was working and not working, so I’m wondering if anyone has any good debug ideas to poke around at these issues?

Edit: I can’t seem to get anything for the odrive on an lsusb either.

Thanks!

This is the error given when the ST-Link’s data/clock lines aren’t connected to the ODrive.
I understand you may have tried this already but just in case:

  1. Power cycle everything: Disconnect ST-Link from usb (so it’s power source is removed), power cycle the ODrive making sure that the green led goes out.
  2. Try with different short jumper wires between ST-Link and ODrive. Double check the pinout.
  3. Do you have a second ST-Link or ODrive (or other STM based board) to try to see if it could be a hardware issue with either?

Thanks for the response. I think I’ve done about all I can do with power cycling and jumper cables.

I don’t have another stlink or any other board- I can order another and check in a few days. My feeling is that in conjunction with the Odrive suddenly not connecting, or showing up in an lsusb, that the issue isn’t my once-used stlink though.

I’m pretty close to ordering another Odrive, but I’m hoping for some closure on this one. It seems to have simply stopped working one minute to the next. I don’t have an Oscilloscope or anything fancy to debug, but I would really like to know what happened.

Do you know if it could have been possible that you had some loose bits of wire or other electrically conductive object make some unfortunate contact on the board?

If you want to send back your misbehaving ODrive we can have a look at it here if you like.

Nothing obvious to me could have done it, though it’s certainly within the realm of conceivable events.

I’d love to send it back for a look-see. What address can I ship it to?

ODrive Robotics
5949 Arlington Blvd
Richmond, CA 94805
USA