开云体育

Hi Larry/OneOfEleven,
Many Thanks for the replies and advice, much appreciated . . And apologies for the slowww response, weekend obligations . . .

These days I tend to just dive in and follow the RTFM Rule; “When all else fails – RTFM” ? And since I’m building some Experimental Antennas that I plan to use for mobile emergency volunteer work I just need to ‘get comfortable’ enough with these gizmo’s to get some idea of how a wire will perform Before I try and poke a few hundred watts into it with an expensive radio . . .

Having said that I did manage to find a few moments to research & scan some info on the DFU mode vs USB protocol by way of getting my head around that.

A few further clarifications if I may . . .

“The White Screen of Death” was just a bit of tongue in cheek based on memories of a great many Windows NT “Blue Screens of Death” most of which were also recoverable.

When I say “bricked” what I mean is that the device becomes completely unresponsive; No screen data, No input, No comms, the physical connection is Not recognised by Windows (no Ping), device is Not in DFU Mode, Nada, Zip . . . In short no apparent way to communicate with the device. This is the ‘shcary’ part . . And it always seems to be displaying a white screen when it goes into this state, hence the “White Screen of Death”.

For some people who may well be expert in Radio/Electronics but are not familiar with microcontroller based devices such as the NanoVNA, that becomes the end of the matter and the device is binned or left in a drawer to gather dust (I inherited an early model & very dusty Pi in just that way).

So knowing how to physically put/’force’ the device into DFU Mode** & to try a different Firmware/.dfu file is what matters. Given that this could also happen during a normal/’routine’ firmware upgrade I think it’s important to be aware that there is a simple reliable physical solution [**By shorting the Boot & VDD pins on the board].

BTW The NanoVNA App does appear to allow me to upload the ‘H4’ firmware to a working ‘H’ model device – it does complain if I try and load it to a ‘bricked’ device. A minor bug/oversight perhaps or does it automagically default to the correct ’H’ firmware?

Hope this helps . .

Kind Regards

Ross

Ross Filippi
VK2ATA

From: Larry Rothman<mailto:nlroth@...>
Sent: Friday, 9 October 2020 1:51 AM
To: [email protected]<mailto:[email protected]>
Subject: Re: [nanovna-users] Help! My NanoVNA bricked after a firmware update! #firmware

Ross,
Welcome to the forum.
Please remember, you can only use nanovna-H4 firmware on an H4 with the 4 inch display and H firmware on anything that is either a Nanovna-H or just Nanovna, with the 2.8 inch display.
If you are using 1of11's app to flash firmware, make sure it matches the family of board you have: H (or earlier) or H4 !!
You cannot brick this unit and there is no 'white screen of death' - a white screen just means you flashed the wrong family of firmware - just flash the correct firmware and you're ready to go.
During DFU mode, there is no active comm port on the nanovna - that is why it's called DFU mode.
Please read up on flashing ST32F series of microprocessors at the ST Micro website.

On Thursday, October 8, 2020, 8:03:35 a.m. EDT, Ross Filipi <rossfi@...> wrote:

Hi All,
I'm new to the NanoVNA too (but fortunately not to microcontrollers) and also managed to 'brick' mine and get the "white screen of death". As one does I had a look around, came across this thread and various others as well as this from Owen Duffy; ;data=02%7C01%7C%7C7d6c4a22ff09470f104908d86b99b27a%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637377655148915989&amp;sdata=c55dniJwSiHSYfs5y2X9Y5TmWKH9LX6T5EQGyI4jWSA%3D&amp;reserved=0

Long story short I wasn't able to connect to the serial/usb port as that had stopped working too - so was unable to apply CT2FZI's solution as neither Putty or Tera-Term (or Windows(10) for that matter) could see a comms port.

What I did find was that if I kept the Boot pin continuously shorted to VDD on the P1 I/face, I was able to get the NanoVNA App by OneOfEleven to upload a new .dfu file (either the preselected ones in the App or external .dfu files (so long as they were 'good')). After that I just rebooted and I was back in business. Bit shcary but all good . . .

Being a brave soul I repeated the process a number of times and have noted that I appear have either;
- a number of bad dfu files or
- a number of dfu files that wont work with the NanoVNA App or
- a flakey NanoVNA Device
At any rate I've established that shorting the Boot pin to VDD & repowering the VNA causes Windows(10) to 'see' the comms port allowing the NanoVNA App to re-load a .dfu file (Reckon I'll be stopping in at Jaycar tommorrow for a tiny switch). Since I've only been 'playing' with this device for a few days I've not yet had a look at other DFU Manager apps as the upload capability in the NanoVNA App was so convenient I just went straight to that.

One odd thing to Note though; Apart from having to keep the boot pin continuously shorted during the reload process - I also noticed that while the NanoVNA App was able to communicate with the VNA for the upload process it didn't seem to be able to recognise a comm port as such (see attached pic) though I could hear the Windows 'ping' that signaled a new usb device.

I hope these observations are helpful . . .

Kind Regds
Ross VK2ATA