This article applies to the original NanoVNA (v1) by edy555 / ttrftech, and the NanoVNA-H derivative.
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 that resides 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. NanoVNA-App does this, but in my experience most PC client programs do not.
A compatibility problem that arises with DFU is that there are lots of client applications for DFU programming, and they tend to use one of two different and incompatible drivers:
- DFUseDemo and the like use STTUB30.sys from ST; and
- STM32CUBEPROGRAMMER and the like use a libusb compatible driver.
Windows associates only one driver with the device in DFU mode. If the associated driver is not compatible with the programming application, it will not work.
So, you probably need to use a programming client, and for Windows one choice is ST’s DfuSeDemo, though it is essentially deprecated. You may need to convert the distributed file format using Dfu file manager from the same distribution, not all developers distribute a .dfu file.
Another choice from ST is their STM32CUBEPROGRAMMER, though it does not handle .dfu file format.
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.
Some later hardware can be booted in DFU mode by pressing the jog button in while powering on.
Above is the rear view of the board, and a jumper using pogo pins to bridge BOOT0 to VDD.
The bootloader does not initialise or write anything to the nanoVNA screen, so the unitialised screen will usually be white or black.
Now the bootloader has its own identity to Windows VID=0x0483, PID=0xdf11, and this needs to connect the compatible driver (see above).
If you cannot connect from DfuSeDemo to the nanovna, it is likely to be that it isn’t in bootloader mode or the correct driver is not properly installed in Windows.
Likewise, If you cannot connect from STM32CUBEPROGRAMMER to the nanovna, it is likely to be that it isn’t in bootloader mode or the correct driver is not properly installed in Windows.
That said, make sure that your USB cable supports data. There are some USB cables that have only power wires, and whilst they permit battery charging, they do not support data and will not support the bootloader.
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.
The expert advice online is to confirm that they have bricked the device and the solution is to use a SWD programmer. This is usually a bad diagnosis, bad advice.
In the very worst circumstance, if the USB interface DFU is not functioning for some reason, an otherwise 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 but you do not want to do this until you are sure you cannot use DFU mode over USB.
There is a STLINK UTILITY, and the ST Visual Programmer, and more recently STM32CUBEPROGRAMMER. My preference is the latter. STM32CUBEPROGRAMMER can be:
- used over the USB interface (using a libUSB family driver); or
- using the SWD interface.
Using the SWD interface
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. Some don’t work with later firmware versions and the later versions of STMCUBEPROGRAMMER refuses to work with older firmware (but will upgrade an older device with suitable chip).
Above is the STLINKV3-MINIE with STDC14 breakout board and jumpers for SWD connection.
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. (nBoot1 must be set to enable the system memory boot loader, this is the factory default.) 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.
Be careful, there are clones that look real (including faked packaging), but they contain a Chinese chip (eg CKS32F103… ) which cannot be loaded with the latest firmware. If you want to be able to upgrade the programmer as new firmware releases occur, perhaps an STLINK-V3 from a reputable seller.
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 above driver configuration suits DfuSe Demo, the STTub30.sys driver file.
Some software uses libusb or variants.
Above is a screenshot of the USBDeview for such a driver setup. Zadig is a good tool for installing this driver, but you can do it in the standard Windows tools.
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.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.
Above, the correct selection. If you cannot find a COM port when the nanoVNA is powered on, check this.
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.
Normal serial port mode
Many NanoVNA use Chbios and the provided USB serial port emulation.
Above is a device properties print for recent DiSlord firmware. I have two devices with the same firmware, at this time they use identical VID, PID, Serial which plays havoc with Windows enumeration… I can only use one at a time.