NanoVNA-App – driver for NanoVNA firmware updates

NanoVNA-App contains a facility to upload / download NanoVNA flash memory using the DFU bootloader.

The appropriate Windows driver filename is STTub30.sys (or later?) from ST.

Above is a properties list from USBDView of the correct driver.

If you wish to use it, make sure that you have not replaced the bootloader driver with something else. The driver is packaged with ST’s DfuseDemo.

A common issue is that users have replaced the ST driver with a libsys based driver, eg for dfu-util.

That does not mean you need to reinstall DfuseDemo, they driver may be there.

Above are screenshots of working down to select an already installed driver. As can be seen, this machine has several drivers that are suitable for the VID and PID of the ST chip in bootloader mode, but it is the first one here that is appropriate for DfuseDemo and NanoVNA-App.

The easiest way to get the correct driver for NanoVNA-App is to install the DFuseDemo package.

Other options?

DFuseDemo is old (though it works fine if you want to use it), and its page on refers to STM32CubeProgrammer software as the replacement / preferred option. STM32CubeProgrammer is a larger download, a more flexible tool (but v2.10 seems not to support .dfu… so it is not a “replacement” and is really inconvenient when the firmware is distributed as a .dfu), but the tool works for me with the libUSBk driver.

Above, STM32CubeProgrammer set up to upload a raw binary file at offset 0x08000000.

Above, STM32CubeProgrammer set up to upload an srec file, offset is handled hands-off. (STM32CubeProgrammer does not accept the generic extension .srec.) The same convenience is achieved with an Intel Hex file.

The lack of support for .dfu in STM32CubeProgrammer makes one wonder whether ST regard .dfu as strategic.

My own practice: I usually use dfu-util from a bat file that finds the latest version .dfu and copies it to the device. dfu-util uses libusbK driver on Windows (which also works with STM32CubeProgrammer.

Choice of tools depends a bit on whether the firmware is distributed as a .bin, .s19, .hex or .dfu… and they are all used, most distributions are only in one format.