I often see reports that a nanovna has been ‘bricked’.
The STM32F072 chip used on the original nanovna has some features that make the firmware update process simple and robust, and difficult to mess up.
The normal way of doing a firmware update is using the DFU protocol from a PC over the USB interface. To use this, the device has to be “put into DFU mode”, this means that the chip is reset and started executing the bootloader in permanent system memory.
The concept of DFU is that normal client programs used with the device can easily be extended to include the DFU function as just another menu function of the client software. I am not aware of any nanovna client that does this.
So, you need to use a programming client, and for Windows a good choice is ST’s DfuSeDemo. You may need to convert the distributed file format using Dfu file manager from the same distribution, not all developers distribute a .dfu file.
There is a pin on the board, BOOT0, that must be held high during reset to enter the on-chip bootloader. Later firmware versions also provide a menu option to enter the bootloader, but if an attempted upgrade messes up the menu, you may need to use the BOOT0 pin bridged to the adjacent VDD pin while you power cycle the nanovna.
Above is the rear view of the board, and a jumper using pogo pins to bridge BOOT0 to VDD.
Now the bootloader has its own identity to Windows VID=0x0483, PID=0xdf11, and this should activate the appropriate driver.
If you cannot connect from DfuSeDemo to the nanovna, it is likely to be that it isn’t in bootloader mode or the drivers are not properly installed in Windows.
When all this seems to fail, users tend to call out that they have ‘bricked’ the nanovna. Well, they probably got there through lack of experience and care, and their diagnosis is probably wrong.
In the very worst circumstance, a working set of electronics can be programmed using a programmer over the SWD interface which is presented on pins at the edge of the nanovna board
There is a STLINK UTILITY, and the ST Visual Programmer. My preference is the latter.
Looking at the pic above, the relevant pins are labelled SWDIO, SWCLK, GND, NRST.
Above is a nanovna and a STLINK-V3 with adapter cable for the SWD interface, here pointed pogo pins are used to made temporary connection to the nanovna during programming.
You can buy Chinese clones of STLINK-V2 for a few dollars on aliexpress, they are fine for this.
The SWD interface allows you to do a mass erase which overwrites all protection and sets the chip into a known state. DfuSeDemo may off the option of a mass erase under some circumstances.
You should then check / set the Options Bytes, the pic above are the options set in my nanovna-H from the factory. Note that if you change the Options Bytes, you may need to power cycle the chip to see the effect.
You could proceed and then program the flash, but I would suggest that you disconnect and try the DFU method of writing the flash (you will need to use the BOOT0 jumper to get into bootloader mode).
The DFU device should appear in “Devices and printers” as “STM32 BOOTLOADER” or “STM Device in DFU Mode”. Much is made about the first being wrong, but it would seem that the strings are just different fields of the device properties as seen in this capture from USBDeview.
There should be no confusion with the STLINK devices, they have their own distinct PIDs and that is what DfuSe should be searching to find.
Now when you worked your way through all of this, you will probably find that the real problem was getting the chip into bootloader mode or Windows driver issues, and that there was no need to mass erase the chip. If you are smart, you will revisit the DFU stuff before resorting to SWD.
I have reloaded flash scores of time using DFU without incident, it just works!
The comments here apply to the STM32F072. Some ST chips may put the bootloader in user flash… and it is possible to corrupt the bootloader during a failed flash update, and in that case, you must load the flash from SWD to get the bootloader back in there.