STM32 DFU cross-OS support

[Matt Blessinger]

Posted on May 27, 2018 at 00:38

I'm working with the Nucleo F767ZIT (QFN-144) to test the F7's abilities, and currently I'm struggling with the USB DFU capability. I've read a few posts about issues getting the DFU working due to the F7 requiring option bytes to be set, but none of them have come across my issues. I'm testing the Nucleo on both macOS 10.13 (High Sierra) and Windows 10 trying to get DFU flashing to work.

The Nucleo doesn't come with a HSE, so I installed the recommended 8 MHz crystal, 4.3 pF caps, and de/soldered the necessary jumpers. I have tested bidirectional USB FS communication without a problem, and I have intentionally invoked the CSS NMI callback to ensure the HSE is running, which it is.

My first issue is trying DFU with the STM32 Cube Programmer in Windows. I first connected to the Nucleo using the STLink and checked that the option bytes were correct to allow DFU. I then held Boot0 high, reset the MCU, and it entered the DFU boot loader. Device manager reported 'STM Device in DFU Mode.' I then went to the USB section in Cube Programmer and it couldn't find the MCU even after clicking refresh and restarting the program.

I then went to DfuSe v3.0.5 and that could connect to the MCU, erase and flash no problem. I have attached a screen shot of the option bytes seen in STLink Utility. Interestingly, nDBOOT shows up on

STLink Utility

but not in Cube Programmer.

To fulfill cross-OS support, I attempted DFU with Cube Programmer in macOS, but that didn't work either. It found a USB device but it had a strange serial number and wouldn't connect to it, giving corruption error messages and unknown device.

I also have a Nucleo F447ZE that I tested. That one works in Cube Programmer in macOS but not Windows.

So to break it down:

• Nucleo F767 works in Windows 10 DfuSe v3.0.5
• Does not work in

  Windows 10

   

  Cube Programmer. USB device not even found.

• Does not work in macOS

  Cube Programmer. USB device found, but with weird serial number.

• nDBOOT option byte doesn't show up in Cube Programmer.

I would love to get this solved, so if anybody has thoughts on what would be causing this behavior, I appreciate any input. Thank you.

#stm32 #stm32f7-nucleo #stm32cubeprogramer #dfu-bootloader

[Ben K]

Posted on May 27, 2018 at 21:56

DfuSe and CubeProgrammer cannot work at the same time on Windows as they use different drivers for the DFU USB device. More on this

https://community.st.com/0D70X000006SIM6SAO

.

[Tesla DeLorean]

Posted on May 27, 2018 at 23:19

Perhaps mac devs collectively can find someone who has experience writing system code and device drivers for the platform? I'd assume ST/Atollic had such individuals at some point, although forum traffic suggests they are like unicorns. Someone in ST management should go shake that tree a bit.

Are there some IOCTL/URB interfaces you can drill into the USB stack with?

[Matt Blessinger]

Posted on May 28, 2018 at 18:12

Thanks for the link! I was completely unaware that problem existed. Given the issues others are facing, I'll be sticking with DfuSe until a new version of Cube Programmer is released.

[Matt Blessinger]

Posted on May 28, 2018 at 18:25

I would be able to help with testing, but that coding is beyond me. Running 

ioreg -p IOUSB -w0 -l

in the terminal yields this screenshot. 

Cube Programmer reports serial number 356435593136, so that at least matches. When I click connect I get ''Corrupted Data base'', ''Error: Device not supported'', and ''Warning: unknown or unsupported device''.

Perhaps it is a driver issue like on the Windows side.