I often see reports that a nanoVNA has been ‘bricked’. The term seems to have become part of the vernacular of would be pros. The term ‘bricked’ certainly applies to electronics that can no longer be programmed through ‘ordinary means’ and is to all intents and purposes as useful as brick, but in most cases, the nanoVNA is recoverable.
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.
The bootloader does not initialise or write anything to the nanoVNA screen, so the screen will usually be white.
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.
You need a file to flash, and they come in various formats.
Above is the low end memory map of the STM32F072x processor, the flash is loaded at offset 0x8000000. You need to provide this information if you load a binary format file which is based at 0x8000000, if you load a hex file (or dfu) this information is contained in the file… so use one of them by preference. ELF files contain the needed image but are not directly usable by most programming utilities.
If developers distributed only one file, a .dfu file would be most useful as it is directly usable for DFU updates, and a .hex file can be derived for SWD updates using DFU file Manager. Not all developers distribute the .dfu file, but you can make it from a .hex file using DFU file Manager.
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 eBay, 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.
Above, a ‘real’ STLINK V2 can be had for less than $10 new on eBay. The case has been discarded as it interferes with the connectors. I say real as it looks real, but is probably a quite detailed clone as the case fitup does not have adequate clearance for the connectors.
The JLink probe pictured above can be used to reset the chip, use the Segger STM32 utility: jlinkstm32.exe” -SetDeviceFamily STM32F0xxxx . Even though the pictured EDU model is quite crippled, it can perform the reset as described and it can write the flash if desired using JLinkCommander.
Above, JFlash Lite works with the crippled EDU probe.
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.
The ‘original’ nanoVNA author ttrftech / Edy555 advises
After updating firmware, recommend doing You probably need to connect to the serial console to do the
touch cal and do
clearconfig 1234, power cycle the device then to the
touch cal and
save from the device menus.
There should be no confusion with the STLINK devices, they have their own distinct STLINK 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! If you do not have a .dfu file, use Dfu File Manager to make one from a .hex file (or a .bin file with offset 0x8000000).
Because the firmware I tend to use is not shipped with a .dfu file, I tend to use a command line utility to upload the extracted ch.exe as follows:
dfu-util-static -a 0 -s0x8000000 -D ch.bin
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 DFU bootloader back in there.
Note that it is common that versions of nanVNA firmware will operate with incompatible saved settings. The usual practice in good designs is for firmware to check version compatibility with saved settings, and if incompatible, to clear or set reasonable defaults. With many if not most or all nanoVNA firware the user must connect to the nanoVNA in terminal mode and enter the command “clearconfig 1234” to clear the settings to a known state and assure reliable behaviour. This will usually require recalibration of the touch screen.
Another problem that I have found is that some software changes the normal driver flavour activated by the nanoVNA application firmware to ChibiOS/RT Virtual Com Port, and it needs to be changed to USB Serial Device so that it presents a com port for various applications.
A somewhat similar problem occurs with the bootloader having multiple flavours of driver that is activated.
The correct driver for DFUse utility is STM Device in DFU mode, but for some other utities (eg dfu-util), it is a libusb driver that is required.