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 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.
So, you probably 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.
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. Continue reading nanoVNA-H – recovery