DFU mode has stopped working

Support
1

I have been working for weeks using the STM32CubeProgrammer workflow as described here. (This is the one that involved flipping the DIP switch between RUN and DFU modes - I did this because iirc the python method didn’t work for me.)

Yesterday I began seeing intermittent behaviour where:

  • the Odrive in RUN mode works fine
  • the Odrive in DFU mode is totally undetected.

When I say ‘intermittent’, I mean that randomly turning it off/on, or plugging/unplugging the usb cable would eventually sort it out. I was unable to find any logic for what change (if any) was actually making it work.

Today the Odrive is totally unresponsive and no amount of messing around will get it to be detected. I have wasted a lot of time with this and found it very frustrating.

The ODrive in RUN mode still functions fine - Windows chimes when it’s plugged in, odrivetool talks to it without problems. So the Odrive itself is healthy, it’s only the DFU mode that’s broken.

I need to be able to update the firmware. The current code running on the Odrive is half-finished and has a bug that renders it effectively useless. (The bug is trivial to fix, but showstopping.)

Zadig does not pick up the odrive in dfu mode. In run mode it sees Odrive 3.6 CDC and Odrive 3.6 Native.

Running odrivetool dfu (in RUN mode) gives this result:

ODrive control utility v0.5.1.post0
Waiting for ODrive...
Found ODrive 20593687424D (v3.6-56V) with firmware v0.5.1-dev
Checking online for newest firmware... found v0.5.4
Downloading firmware v0.5.4...
Saving configuration to C:\Users\tog\AppData\Local\Temp\odrive-config-20593687424D.json...
Configuration saved.
Putting device 20593687424D into DFU mode...
Still waiting for the device to reappear.
Use the Zadig utility to set the driver of 'STM32 BOOTLOADER' to libusb-win32.

‘STM32 BOOTLOADER’ never appears in Zadig’s device list.

I was already far behind schedule with what I was doing before this happened.

Can anyone tell me what is going on?

2

Update:

The Odrive is now unresponsive in RUN mode as well and I would really, really appreciate if someone would chime in and help me.

Steps taken:

If the DFU was not going to work for me, I wanted to instead use the STlink on a Nucleo-F7 I have. I have no other STM32 boards and no standalone STlink.

I put the ODrive back in RUN mode.

I removed the jumpers on the Nucleo-F7’s STlink section CN4, and wired the Nucleo’s STlink section CN6 to the ODrive’s J2 as follows:

Odrive J6 — Nucleo-F7

  • 5V → nc
  • 3.3V → pin 1 (VDD_TARGET)
  • SWC → pin 2 (SWCLK)
  • GND → pin 3 (GND)
  • SWD → pin 4 (STDIO)
  • ~RST → pin 5 (NRST)
  • nc → pin 6 (SWO, ‘reserved’)

I did this based on the table in page 19 of the manual I found here.

On plugging in the Nucleo-F7, I was able to see an ST-LINK appear in STM32CubeProgrammer.

(At this point I pressed ‘Firmware upgrade’ to let STM32CubeProgrammer update the STlink to the latest version. This completed without any issues.)

On Pressing Connect, I got the message Error: No STM32 target found!

I then powered on the ODrive and this time I was able to connect. (It seems the 3.3V wasn’t there to power the chip, as I’d initially thought. What was it there for then?)

From there I found an older and trusted hex file, ODriveFirmware_v3.6-56V.hex and downloaded it using the same Open File → Download workflow I’ve been using all along.

This is the log from STM32CubeProgrammer of the download (including my disconnecting after it completed):

18:08:48 : Read File: D:\ODriveFirmware_v3.6-56V.hex
  18:08:48 : Number of segments: 1
  18:08:48 : segment[0]: address= 0x8000000, size= 0x38604
  18:08:51 : Memory Programming ...
  18:08:51 : Opening and parsing file: ODriveFirmware_v3.6-56V.hex
  18:08:51 :   File          : ODriveFirmware_v3.6-56V.hex
  18:08:51 :   Size          : 230916 Bytes
  18:08:51 :   Address       : 0x08000000 
  18:08:51 : Erasing memory corresponding to segment 0:
  18:08:51 : Erasing internal memory sectors [0 5]
  18:08:54 : Download in Progress:
  18:08:56 : File download complete
  18:08:56 : Time elapsed during download operation: 00:00:04.638
  18:09:03 : Disconnected from device.

No errors or complaints at all.

However, now when I plug in the ODrive in via USB, Windows does not chime, odrivetool does not pick it up and nor does Zadig. The green power LED comes on but for all other intents and purposes it’s bricked.

I am out of my depth and have no intuition for what might have happened.

I would very much appreciate it if someone could tell me what I did wrong and whether it’s fixable.

3

The VDD_TARGET is there only to detect the target voltage, so that the ST-Link can choose the correct logic-level-shifter voltage.
The ODrive needs to be plugged in to a power source during the firmware upgrade.

Do you have any Linux computer e.g. raspberry pi to test this on? You can get useful info about USB devices from the sudo dmesg -w command.

4

I don’t have access to any other computers, only this Windows one. What extra information am I looking for? Maybe there’s an equivalent Windows command.

Is there any reason what I did shouldn’t work? Is there some nuance to downloading firmware that I’m missing?

5

No, flashing with STM32CubeProgrammer or STLink or odrivetool dfu should all work equivalently. Not working in DFU is quite strange, that makes me think you don’t have the STM32 BOOTLOADER drivers or something :thinking: