No connect, now a brick

Support
1

I’m now into week 2 trying to initialize Odrive. Odrive 3.6 on Windows 10. Initially Windows Device manager displayed the Odrive both as a Port and as a USB device. But odrivetool would not connect to it. Initially a ‘no backend’ error. After i resolved that, it just looped forever looking for the device (even though Windows knows about it, and i could see the whole USD descriptor, serial number vendor and product ID, and all, in the log traces). But i was able to connect an FTDI cable to the UART_A interface and use the ASCII Protocol, briefly.

Then i powered off to recharge the battery, and then plugged it back into Odrive. Now the UART interface never responds. With the plain USB cable Device Manager no longer displays anything about Odrive. Odrivetool still fails to connect. Odrivetool dfu does not connect either (with the DFU switch in either DFU or RUN position). There is no “STM32 Bootloader”. So basically, i have a brick.

My guess is the firmware got corrupted by a power in-rush. If so, that is VERY sensitive! And how am i supposed to download new firmware if it won’t connect to my PC ?

EXTREMELY fragile and unusable so far. Can anyone save me ?

2

It’s a good idea to use anti-spark connectors e.g. XT90-S with any battery that has a voltage close to the max input voltage. Otherwise with low-resistance batteries and wiring, there can be an inrush surge in the thousands of amps which can destroy various components by overvoltage, usually the M0 DRV chip which also supplies the 5V.
Check that you have a correct 5V and 3.3V on the board, and that the STM32 is not getting warm.

I would also advise using a Linux environment, e.g. a raspberry Pi. libusb support on Windows is just awful, due to the Windows driver model.
On Linux you can check sudo dmesg -w to see exactly what the ODrive is identifying on USB as.

The DFU bootloader which is activated by the switch is baked into ROM on the STM32 so you cannot accidentally erase it. More likely, some component was damaged by overvoltage due to the inrush surge.
That said, you could try programming with an ST-Link (any STM32 ‘nucleo’ dev kit comes with an ST-link included)

3

I don’t know if they are anti-spark, but i’m using EC5 connectors. Plus i have a high-line switch downstream of the batteries, so battery connect-disconnect has no impact on the Odrive. I’m using 12S (44.4V) batteries on an Odrive3.6-56V, so i’m not close to the edge. I saw nothing on the site recommending any kind of inrush protection circuit. I DO have 5V and 3.3V on the board, and the normal LED. Nothing on the board is hot.

I get that you are a Linux fanboy. But my platform is Windows 10, and thats not going to change. The product page advertises ODrive as working “over USB from a PC” using Python.

After 24 hours cool-down and power cycling everything, i got an “STM32 BOOTLOADER” in Device Manager when DFU switch was set (nothing when in switch set to RUN). So i tried “odrivetool dfu”. It seemed to confirm my theory about a trashed firmware. But then it failed to update, without telling me anything useful. i don’t know what device status (0,2,0,0) means.

Found ODrive 205337925753 (v3.6-56V) with firmware [unknown version] in DFU mode
Checking online for newest firmware... found v0.5.3
Downloading firmware v0.5.3...
The configuration cannot be backed up because the device is already in DFU mode. The configuration may be lost after updating. Do you want to continue anyway? [Y/n] Y
Erasing... done
Flashing... (sector 0/7)
---------------------------------------------------------------------------
RuntimeError                              Traceback (most recent call last)
c:\programs\Odrive\Python3.8.6\Scripts\odrivetool in <module>
    141         print_version()
    142         import odrive.dfu
--> 143         odrive.dfu.launch_dfu(args, logger, app_shutdown_token)
    144
    145     elif args.command == 'liveplotter':

c:\programs\Odrive\Python3.8.6\lib\site-packages\odrive\dfu.py in launch_dfu(args, logger, cancellation_token)
    463     firmware = FirmwareFromFile(args.file) if args.file else None
    464
--> 465     update_device(device, firmware, logger, cancellation_token)
    466
    467

c:\programs\Odrive\Python3.8.6\lib\site-packages\odrive\dfu.py in update_device(device, firmware, logger, cancellation_token)
    391         for i, (sector, data) in enumerate(touched_sectors):
    392             print("Flashing... (sector {}/{})  \r".format(i, len(touched_sectors)), end='', flush=True)
--> 393             dfudev.write_sector(sector, data)
    394         print('Flashing... done            \r', end='', flush=True)
    395     finally:

c:\programs\Odrive\Python3.8.6\lib\site-packages\odrive\dfuse\DfuDevice.py in write_sector(self, sector, data)
    199             status = self.wait_while_state(DfuState.DFU_DOWNLOAD_BUSY)
    200             if status[1] != DfuState.DFU_DOWNLOAD_IDLE:
--> 201                 raise RuntimeError("An error occured. Device Status: {!r}".format(status))
    202
    203     def read_sector(self, sector):

RuntimeError: An error occured. Device Status: (0, 2, 0, 0)
type or paste code here
4

Please use a linux device or one of the alternate flashing methods on Windows; ODrive Tool | ODrive

Personally, I recommend just getting an STLinkV2 and flashing that way. Way less hassle.

5

Sheesh, just trying to help, mate. :roll_eyes:
I said “e.g. a raspberry pi”. That doesn’t mean you need to reinstall your PC operating system. Just SSH or VNC to the Pi and use ODrive from there, if you want to get round all of the libusb problems on Windows.
That, or use the ST-Link (but make sure you back up your config manually first if you use this method again later)

6

Just for the benefit of all…
I was able to successfully use the STM32CubeProgrammer tool described on your docs pages (and was able to download it without setting up an account). The method described on that page did not work for me. The download failed, but reported an error on the ‘erase’ step. This seemed similar to the report i got from ‘odrivetool dfu’. The ‘erasing and programming’ command button on the ST tool gave me more precise control. I skipped the erase step and the new (0.5.3) firmware downloaded and verified successfully. The tool claims to work via either USB, UART, or STLink. I did buy an STLink. But i tried USB first, and it worked. And i agree - i found the tool very robust and easy to use.
I now have an Odrive (3.6-56V) connected in RUN mode via USB to odrivetool in Native Mode on Windows.

2 Likes