开云体育

19
Hello, Peace be upon Yours All.
Yesterday i updated my firmware from the NanoVNA-H4_20200124 version to the NanoVNA-H4_20200221version.
The reason was, i could not save settings.
The firmware update ran smooth and the verification was done. After disconnecting and new start, i get a white screen, the usb is not anymore recognized,
Also with jumper set, a new flashing is not possible. What can i do?
Thanks for help.
Sincerely
** Ari **

Hi Ari,
The H4 allows you to go into DFU programming mode if you hold the jog switch in while turning-on the unit. Make sure the jog switch AND the Boot0 jumpers are not engaged when turning on the unit.
Due to the way the STM32F303 is set up, you should not be able to corrupt the boot sector (Hugen/Ken, correct me if I'm wrong for the F303).
Lastly, remove the front cover of the unit and apply power - on some units, the front bezel pressed on the touchscreen surface and caused the device to hang.
If the unit works with the front cover removed, search the forum messages for the thread about adding spacers to the case.
I hope this helps.
...Larry

19
Hi Larry, Peace be upon You.
Thnks for Your reply, no chance the device is not loading.
Just a white screen, no dfue mode possible, also no handshake with windows, even no error.
Sincerely
** Ari **

On Tue, Feb 25, 2020 at 10:23 AM, <19.ari@...> wrote:

19
Hello, Peace be upon Yours All.
Yesterday i updated my firmware from the NanoVNA-H4_20200124 version to the
NanoVNA-H4_20200221version.
The reason was, i could not save settings.
The firmware update ran smooth and the verification was done. After
disconnecting and new start, i get a white screen, the usb is not anymore
recognized,
Also with jumper set, a new flashing is not possible. What can i do?
Thanks for help.
Sincerely
** Ari **

Hi ari.19,
I have an H-4 and I think I have fixed several prototype bugs.
When upgrading a DFU, the screen will remain black for –H4, unlike the “basic” version.
Following the description of the error, first remove the plastic cover on the screen.
1. If you log in to the nano after removing the lid, the lid is causing the problem.
Solution: Use a plastic washer between the PCB and the cover to raise the top cover.
2. Turn on: if there is no change, turn it off.
If your computer is running Windows, you can use USBDeview to see if there is a "green" line connecting your nano to your computer, showing which driver is in use.
When working properly, “STM Device in Bootloader mode” will turn green when nano is in “DFU” mode.
Delete the faulty drive and turn on the –H4 while holding down the menu selector switch. That is, when you enter DFU mode, the screen stays dark, you plug in your computer's usb and you watch this "green" line of the correct driver appear.
You will then launch DfuSe Demo and upgrade the firmware.
Bottom “Choose… select file and“ Upgrade ”.
Finally you turn off the device and remove the usb connection.
If everything worked well, you should work it on when you turn it on.
3. If this did not work, I would first look to see if there was any damage to the PCB. If not, hugen or Ken will help you with what you need to configure with ST-Link v2-dongle to upload a * .hex file using the ST-Link Utility.
Hope I can help with this description
73, Gyula HA3HZ

19
Hi Gyula, Peace be upon You and Yours All.
I tryed everything above. But the device will not be recognized from windows no usb. To load the device is no problem, but no handshake.
Sincerely
** Ari **

On Wed, Feb 26, 2020 at 07:41 PM, <19.ari@...> wrote:

19
Hi Gyula, Peace be upon You and Yours All.
I tryed everything above. But the device will not be recognized from windows
no usb. To load the device is no problem, but no handshake.
Sincerely
** Ari **

Eureka
Then what do you have to do?
Look for a driver that can handle bootloader mode.
It's all google, because whatever you post here, you can only guess where and what to help.
I found a link that might help:


or reinstall the DfuSe demo.

19
Hi Gyula, Peace be upon You and Yours All.

"or reinstall the DfuSe demo." Your last words where the key.
I could revoke the device with jumper setting.
Then i saw my ignorance, i updated from NanoVNA-H_AA_20200118 to NanoVNA-H4_20200221 version.
Everything good in the End, Thanks for Your inspiration.
Thanks All.
Sincerely
** Ari **

Hi Ari,

It's great you found your mistake.

So - it appears you flashed an H4 device with H firmware.
The H4 device uses an F303 micro whereas the H and older Nanovna all use the F072 micro.
They are NOT the same - they have different displays and interfaces.

In the future, please be sure to flash a device only with firmware designed for that specific device.

Now you get to play with it!
Please read the various user guides (there are several) on the forum WIKI and in the Files section.

On Thu, Feb 27, 2020 at 10:27 AM, <19.ari@...> wrote:

".. i updated from NanoVNA-H_AA_20200118 to NanoVNA-H4_20200221 version..."
=========================================================
I wondered what the symptom would be if someone accidentally installed the NanoVNA-H4 firmware on the NanoVNA-H, and I guess you answered that unintentionally. Fortunately, you had a NanoVNA without a case or you would have had to take it apart in order to access the pins for getting into DFU mode.

I suppose if the reverse occurred and firmware for the NanoVNA-H was installed on the NanoVNA-H4, similar symptoms would be experienced. Without the correct firmware, I'm not sure if you would still be able to get back into DFU mode on the NanoVNA-H4 by depressing the jog wheel switch while powering on. If not, opening the case to access the pins for getting into DFU mode would be necessary. Then again, getting into the DFU mode on the NanoVNA-H4 might be hardcoded in the OS and would work regardless.

Probably a question for hugen or erik to answer.

- Herb

19
Hi Herb, Peace be upon You and Yours All.
I had to reinstall the software and take my Nanovna - H apart and using a jumper to revoke it.
I tryed bevore without installing the software new, no chance, also zadik could help.
only the hint from Gyula could help.
I will be very careful in the future, but still there is no posibility to save my settings,
that was the reason to update.
Sincerely
** Ari **

Hello ari @ tell me please belchen jumper to revive you had set, thank you for answer.

Sincerely, detlef

On Sun, Mar 1, 2020 at 12:14 AM, <detlef.kerl@...> wrote:

Hello ari @ tell me please belchen jumper to revive you had set, thank you for answer.
======================================================================

Detlef,
Please refer to using the "BOOT0" pin on the NanoVNA PCB to enter DFU mode at /g/nanovna-users/files/Firmware/Windows%20guide%20on%20how%20to%20write%20firmware.pdf .

This method is required to load firmware if you can't access DFU mode from the NanoVNA menu (i.e. first-generation firmware or corrupted firmware).

- Herb

Hello Herb, OK thanks for the quick reply,
I also saw what those pins are,
Was after the re-boot and close the pins again contact via USB dial-up tool, thank you very much
br detlef

-----Ursprüngliche Nachricht-----
Von: [email protected] <[email protected]> Im Auftrag von hwalker
Gesendet: Sonntag, 1. M?rz 2020 10:13
An: [email protected]
Betreff: Re: [nanovna-users] Nanovna white screen USB dead #firmware #nanovna-h4

I did the same thing just a bit ago, but with a different firmware. I was
able to shut down the NanoVNA (wait until the light goes out), short the
two pins, power back on. The USB bootloader was once again available and I
flashed the correct firmware.

On Thu, Feb 27, 2020 at 07:45 PM, hwalker wrote:

I wondered what the symptom would be if someone accidentally installed the
NanoVNA-H4 firmware on the NanoVNA-H

I just did this (unintentionally!) on my NanoVNA Mk1 and can confirm that the instructions re entering DFU mode in the Windows guide are correct. (I'm using linux.)

After the jumper connection is removed the device shows up in DFU mode on the USB bus and can then be flashed with the correct firmware.

Panic over :)

glad you've got it sorted. BTW, is there any DFU tool on linux?

There are a multitude of forum messages that detail how to flash the DFU file in Linux.
It's also mentioned in the various user guides in the forum files area.
A quick search of messages using search terms: DFU and LINUX finds:
/g/nanovna-users/topic/34145802#2437

Hi David,

BTW, is there any DFU tool on linux?

You may want to check the repositories for your particular Linux distribution to see if they include a package for one of the DFU tools. When I searched for DFU on SuSE Linux (with some optional repositories enabled), I found 3 of them: dfuutil, dfu-util and dfutool.
I had no problems detecting the NanoVNA but did ran into a problem when I tried to flash the new firmware.
The NanoVNA has a different Device Id when it is in DFU mode then when it is in normal operation. The firmware file contains the Device Id for the NanoVNA in normal operation, but the NanoVNA must be in DFU mode for the firmware upgrade.
The DFU utility was comparing whether the Device Id in the specified firmware file was compatible with the Device Id on the command line and refused to upgrade because of a detected mismatch.
If the NanoVNA is the only DFU capable device connected to your computer then the easiest way to avoid the problem is to not specify any Device Id at all. Unfortunately I was not so lucky and on top of it, the offending DFU capable device with built-in and not easily removed.
The fix for me was to provide a partial (wildcard) Device Id. The Device Id consists of two values, the Vendor Id and the Product Id. Since the Vendor Id portion is the same when in DFU mode or normal mode, I specified only the Vendor Id on the command line.

As can be seen from the examples for NanoVNA firmware upgrades on Linux, this problem with the Device Id check does not apply to all versions of the DFU utilities/tools.

73,
Thomas