Newly supplied Odrive does not communicate

Support
1

I bought a new Odrive recently, and today I attempted to turn it on.

I get the power LED lighting up, but zero response when I plug the USB in.

I cannot see any visual imperfections on the board, everything looks clean. Nonetheless, the drive is unuseable.

Please advise.

2

Can you check it in DFU mode? You should get STM32BOOTLOADER showing up

3

Huh. Okay:

  • When I plug in the Odrive initially, I can see the Odrive Native and Odrive CDC show up in Zadig.
  • When I switch to DFU mode, I see nothing at all show up in Zadig. This means I can’t flash the chip with the firmware I need to using STM32CubeProgrammer.
  • When I hook up J2 to an external programmer (with the Odrive back in RUN mode), I am able to upload the firmware using openocd. I get a few ‘Info’ readouts and then:
    wrote 262144 bytes from file ODriveFirmware.elf in 7.552458s (33.896 KiB/s)
    – this is as far as I got ten days ago, before coming back to it today.
  • When I plug the Odrive in, it is totally unresponsive over USB; hence my making this post.
  • When I swap to DFU mode, it remains totally unresponsive.
  • However, when I remove the cables between J2 and the programmer, I can suddenly see the Odrive again. (Even thought the programmer was completely unpowered and disconnected from the computer.)
  • Swapping back to DFU mode and once again nothing shows up at all.

As long as my firmware is actually being uploaded, I can work by repeatedly disconnecting and re-connecting the J2 cables.

But is this the expected behaviour?

And why would the DFU mode not work correctly?

What is that RUN/DFU dip switch actually physically doing? I didn’t see it on the v3.4 schematic.

4

Do you have anything plugged into the GPIO? GPIO6 is interlocked with DFU and external devices can do funny things

image
image723×339 25 KB

5

Nope, GPIO6 was connected to GND.

How does the DFU work then?

6

The DFU switch grounds the “BOOT0” pin of the chip, which causes it to jump to a special bootloader address in ROM at power-up. This ROM is not modifiable, so it shouldn’t be possible to brick it …

You can only switch between RUN and DFU modes with a power cycle.

Not sure what GPIO6 is about.

What does ‘unresponsive’ mean? Do you get any message about a malfunctioning USB device or any ‘noise’ that you plugged in some device?
It sounds like you’re on Windows (you mentioned Zadig) and the Windows USB driver stack is pretty hostile to open source (libusb) drivers. You can try “uninstall device and delete driver” in device manager, which sometimes fixes it.
If possible, can you plug it into a Linux host e.g. a Raspberry Pi and monitor the output of
sudo dmesg -w
There is a lot of helpful diagnostics from the Linux kernel about USB devices that you just don’t get in Windows.

7

I have sometimes seen this with ST-Link programmers. Sometimes, if they are unpowered, they will hold the chip in RESET. Other times, they do not.
Don’t leave a programmer plugged in to the ODrive if it’s not being used.

1 Like