Hi Ernest,
Don¡¯t be afraid of experimenting with different .dfu files/foimware (scuse the Bronx accent), I think you¡¯ll find that there a re many that will work and some that don¡¯t. What¡¯s important is the feature sets that the programmers are working hard to provide . . .
Regds Ross
Ross Filippi
0424-317-705
VK2ATA
From: ERNEST AEC-RADIO<mailto:aecradio1@...>
Sent: Tuesday, 13 October 2020 4:55 AM
To:
[email protected]<mailto:
[email protected]>
Subject: Re: [nanovna-users] Help! My NanoVNA bricked after a firmware update! #firmware
I found (by accident), that my version of the H-4 WITH the card holder,
would NOT work with the firmware update for the card. This is why the
screen went windows on me.
For the usual fecal funnies, I loaded the firmware that had no SD card
support...BINGO!
Back to normal!
V.0.9.1.0.dfu is the correct version (for my unit).
I hope this helps others suffering from SD card delusions of grandeur.
73!
KA9UCE
On Sun, Oct 11, 2020, 10:26 PM Ross Filipi <rossfi@...> wrote:
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 ¨C 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 ¨C 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%7C27e9199e34e64353eebe08d86ed7fbac%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637381221231672388&sdata=pdR4XkdMKWam%2FY17Fam%2Fc9KLSwlbMUTdGHIN%2BwKlWKA%3D&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
