|
I have just tried to update my NanoVNA firmware and this ended in disaster! The NanoVNA now boots to a white screen and nothing else happens. I can't even get into DFU mode.
My previous firmware reported that I had the -H version so I downloaded the firmware from here:
I followed the instructions here:
Both sources quote the similar but not quite identical command lines for the .bin file:
dfu-util -d 0483:* -a 0 -s 0x08000000:leave -D ch.bin
dfu-util -d 0483:df11 -a 0 -s 0x08000000:leave -D ch.bin
I used the fist and just substituted the name of the downloaded file:
dfu-util -d 0483:* -a 0 -s 0x08000000:leave -D NanoVNA-H4_20200221.bin
Upon restart I got just a white screen. I have tried bridging the two pins at P1 but can't get the unit back into DFU mode.
|
Phew! I discovered that despite the white screen that when I join the pins at P1 the NanoVNA was, in fact, in DFU mode. It just wasn't telling me so. I downloaded the edy55 version and flashed that to the device and it now comes up.
All this because I am trying to apply the SWR format against a specific trace and couldn't see how to select the trace I wanted to apply the setting against in the existing firmware. It only applies to trace0 and always reads 1:1!
|
The Nano VNA is now totally messed up. The edy55 firmware worked but there were issues with it. For example the rocker switch did not work. Tried to go back to the hugen97 firmware but gort the white screen again and this time no DFU mode in the background so now I'm totally stuck. If anyone has any other ideas it would be appreciated.
|
Connect to serial [use putty for example] and use command: clearconfig 1234
*73 de Lu¨ªs, CT2FZI*
*QRV @ 145.300 MHz | **CQ0VMST (VHF REP Monsanto)*
<>
<>
toggle quoted message
Show quoted text
On Mon, 27 Jul 2020 at 15:43, John <subs@...> wrote: The Nano VNA is now totally messed up. The edy55 firmware worked but there
were issues with it. For example the rocker switch did not work. Tried to
go back to the hugen97 firmware but gort the white screen again and this
time no DFU mode in the background so now I'm totally stuck. If anyone has
any other ideas it would be appreciated.
|
Ok, managed to get the edy55 version back on an working. I then discovered that in earlier releases of the hugen77 code there is an additional "antenna analyser" i.e "AA" release with a note saying it has "4 traces". Files for the AA variant are not present in the latest release. The original -H firmware had four traces so I tried the 18 Jan 2020 "AA" release and am relieved and glad to say that it worked. The NanoVNA is back in business.
I have logged an issue on the authors GitHub as I'm not sure whether this is down to not using the "AA" release or whether there is a problem per se with the latest version.
|
I'd use DiSlords latest firmware myself, it has more options and is more efficient (faster).
|
Hi John,
I recommend you take note of the history of the device because based on your typing, I believe you are lagging behind the line of progress.
Please go to my web page where I try to keep the topic fresh. Although I must admit it does not provide a complete overview either. Then it is worth reviewing the "Wiki" and "Files" pages of the forum, as the essence of what was said on the forum has been gathered.
If you still find a missing link after this, feel free to post in the forum.
73, Gyula HA3HZ
--
*** If you are not part of the solution, then you are the problem. ( ) ***
|
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;
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
|
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.
toggle quoted message
Show quoted text
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;
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
|
As Larry says, the VNA is either in DFU mode OR normal USB serial mode, not both at the same time.
So while the VNA is in DFU mode it has no comport to be seen by the PC, the comport will return once you've uploaded firmware and rebooted the VNA.
.
|
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%7C7d6c4a22ff09470f104908d86b99b27a%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637377655148915989&sdata=c55dniJwSiHSYfs5y2X9Y5TmWKH9LX6T5EQGyI4jWSA%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
|
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
toggle quoted message
Show quoted text
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%7C7d6c4a22ff09470f104908d86b99b27a%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637377655148915989&sdata=c55dniJwSiHSYfs5y2X9Y5TmWKH9LX6T5EQGyI4jWSA%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
|
What version of firmware not work? You can run for example LSE version and not install external quartz (then firmware not run).
|
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
|
Ross: I concur, I am trying several, and had just decided to 'downgrade'
for the time being..
No big deal, but I do miss the graph/scale on the right side.
I believe I returned to: 20200221.dfu.
The other firmware I used for was for the Nano VNA-F series, which was a
breeze to update!
Thanks for your assistance!
toggle quoted message
Show quoted text
On Mon, Oct 12, 2020 at 2:59 PM Ross Filipi <rossfi@...> wrote: 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
|
Ernest, You¡¯re welcome. Only found out about the NanoVNA about a month ago myself ¨C having more fun than a pig in a mud patch - just wish I had more time to really deep-dive these things, but I have some antenna projects with a higher priority. Regds Ross Ross Filippi 0424-317-705 VK2ATA From: ERNEST AEC-RADIO<mailto:aecradio1@...> Sent: Tuesday, 13 October 2020 9:06 AM To: [email protected]<mailto: [email protected]> Subject: Re: [nanovna-users] Help! My NanoVNA bricked after a firmware update! #firmware Ross: I concur, I am trying several, and had just decided to 'downgrade' for the time being.. No big deal, but I do miss the graph/scale on the right side. I believe I returned to: 20200221.dfu. The other firmware I used for was for the Nano VNA-F series, which was a breeze to update! Thanks for your assistance! On Mon, Oct 12, 2020 at 2:59 PM Ross Filipi <rossfi@...> wrote: 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%7C91d006915d7046799c6b08d86efb1d6e%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637381372089522167&sdata=GOWNDIEWDCv8eq2vZw1ygJ0Y56fouebxSxGVTVskYwg%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
|
Hi,
Because it is in .dfu mode when performing a firmware upgrade, terminal programs do not see the device on COMport.
Solution: Physically, BOOT0-to-Vdd is kept in DFU mode at power on. This is followed by the DMR memory cleaner .dfu, then you can upload the .dfu of the firmware you want to use.
The cleaning program can be found in the Files folder in the group as DMR-CLEAR_MEMORY_DFU.dfu. See also message #18174.
73, Gyula HA3HZ
--
*** If you are not part of the solution, then you are the problem. ( ) ***
|
CT2FZI
Gyula Molnar
