STM32 DFU driver for Windows 11 ARM

[dmazan]

Windows for ARM processors has been out for 3-4 years now.  Most of the recent Surface devices use a Snapdragon ARM processor.  I can't seem to find a way to use STM32CubeProgrammer or any other software that requires a DFU connection on these machines.  Am I missing something or are there no DFU drivers for Windows ARM?

[Andrew Neil]

Related: STM32CubeProgrammer on Raspberry Pi (or other ARM-based Host) ?

[dmazan · Accepted solution]

A DFU driver for Windows ARM may be a different situation than running STM32CubeProgrammer on a Raspberry Pi.  STM32CubeProgrammer runs just fine under Windows ARM (emulating x86).  And there are some hacks to make the existing x86 drivers work but they are fairly nasty.

Intel has fallen a bit behind when it comes to integrating AI with their CISC processors.  The Lenovo ThinkBook and ThinkPad laptop lines, IdeaCenter and ThinkCenter desktops and the Microsoft Surface line are all now mostly SnapDragon ARM processors with integrated AI processors.  Apple has already moved on from Intel processors to its own M-series ARM processors.  STM32CubeProgrammer and the DFU driver already natively support Mac ARM processors.

Seems like support for Windows ARM is going to be pretty essential unless you want to keep an old x86 machine around just to program your STM devices.

[Pavel A.]

Intel has NPU-enabled Core Ultra and Lunar Lake processors for AI (copilot) PCs. for example:

* Dell XPS 13 9350 with Core Ultra 7 256V (8-core)

* Acer Aspire 14 AI with Core Ultra 5 226V
* Asus Zenbook S 14 UX5406 with Core Ultra Series 200V

But this is not relevant for the topic ))

Microsoft has dropped the ball. They could easily allow installing INF-only x64 driver packages (that use in-box binaries) on ARM systems, but they didn't. Users cannot just edit the INF files because this breaks the signatures.

[dmazan]

Thanks for the upvote but when is ST Micro going to offer a Windows ARM driver?  It's not that hard to do it with emulation.  Can't imagine how it's been ignored for years.

Of course native Windows ARM support, like currently exists for Mac, would be better.  But ignore ARM processors at your market peril.

[dmazan]

Microsoft doesn't allow INF-only driver package as a security measure.  You can disable that protection with some effort, which is the basis of the hack that would allow you to use existing x86 drivers.

But it's really ST Micro that has dropped the ball.  At a minimum, offer the x86 driver with proper signatures.  Better, just compile the thing for ARM.  

[Pavel A.]

INF-only driver packages do exist, but MS in their alternative wisdom hasn't made them architecture-independent (this should be trivial because the needed binaries are already in-box, and registry info is same for any arch).

/* And I've asked them several times when I was in the position for that.*/

They even went that far as broke the famous Zadig installer on ARM, by strengthening signature requirements.

Fortunately there's a way to write a program that *almost* mimics what Zadig does on x86/x64 on ARM. Such program can replace the ST-Link driver installer for ARM PC, but not perfectly: user action will be required. So yes, better ST should move their moving parts and provide signed package for ARM.