Keyboard Shortcuts
ctrl + shift + ? :
Show all keyboard shortcuts
ctrl + g :
Navigate to a group
ctrl + shift + f :
Find
ctrl + / :
Quick actions
esc to dismiss
Likes
- Nanovna-Users
- Messages
Search
|
Re: New Problem (Bricked?) Re: Trouble Setting Up DFuSE Driver
A bad value in nboot1 would cause the nano to try to boot from RAM ratherif a fw load has a different value for nboot1 than the original code than the system ROM - but that bit is in the "options" registers, which cannot be written to by a normal flash load sequence -- they cannot be easily corrupted. Writing to the option bits requires a very protected sequence, including writing specific key values to special registers to unlock the programming of the option bits. This design makes it virtually impossible to 'brick' a STM32-based design with a firmware update, as long as you can assert the boot0 pin to put it in bootloader mode. |
|
Re: Taming the Smith Chart Beast
#schematic
Just go straight to the W2AEW stuff, it's all top-notch:
Smith Charts (8 videos): NanoVNAs (17 videos) (Naturally, there is a lot of overlap between the two lists.) |
|
Re: New Problem (Bricked?) Re: Trouble Setting Up DFuSE Driver
The bootloader runs first, before you get to any of that . . . (that's kind of the point of having a bootloader). If you flash to he wrong offset, yeah, it won't run, but you should be able to reflash via the bootloader . . . since it will still be intact. (In this case, the flashing code is part of the bootloader, not extenal in the program space).
toggle quoted message
Show quoted text
On January 23, 2023 11:29:04 PM CST, Al Waschka <awaschka@...> wrote:
--
Sent from my Android device with K-9 Mail. Please excuse my brevity. |
|
Re: New Problem (Bricked?) Re: Trouble Setting Up DFuSE Driver
controlled by separate hardware, making the units "unbrickable".casts some doubt on the prevalent opinion that the boot code is Since you are a retired engineer, like me, perhaps this quote from introduction of the bootloader app note (AN2606) for the STM32 ARM processors (which the nanoVNA is based on), will confirm for you the assertion that you cannot overwrite the bootloader, and thus cannot brick the nanoVNA with a firmware update: "The bootloader is stored in the internal boot ROM (system memory) of STM32 devices, and is programmed by ST during production. Its main task is to download the application program to the internal Flash memory through one of the available serial peripherals (such as USART, CAN, USB, I2C, SPI)." Table 5 also clarifies that the System Memory block where the boot loader is stored is ROM and supports only read operations, not write or erase. The bootloader is in hardware ROM which cannot be altered by any software method. This design is why such a program as DFuseDemo by the vendor can be used to bootload any of their microcrontroller devices - it is independent of user programming. Stan On Mon, Jan 23, 2023 at 9:29 PM Al Waschka <awaschka@...> wrote:
|
|
Re: New Problem (Bricked?) Re: Trouble Setting Up DFuSE Driver
Greetings, I apologize if my question is redundant. But, I am a bit confused, and I wonder if you would clarify for me.?Are you saying the vna doesn't appear in device manager at all, or is it listed but has an error (a yellow ? Question Mark as an example).?By the way, I very much agree that the cable could be bad. In fact, the USB cable that came with my NanoVna when it was new was?defective. This actually caused an issue similar to what you are experiencing when I first attached the device to my PC. But, even?after obtaining a good cable (an extra USB A to C cable that came with A Samsung Cellphone as I recall) I think I still had to use?Zaidig to get the driver situation corrected.
toggle quoted message
Show quoted text
On Tuesday, January 24, 2023 at 12:29:16 AM EST, Al Waschka <awaschka@...> wrote:
QUOTE -----Original Message----- From: [email protected] <[email protected]> On Behalf Of Tim Dawson Sent: Tuesday, January 24, 2023 12:03 AM To: [email protected] Subject: Re: [nanovna-users] New Problem (Bricked?) Re: Trouble Setting Up DFuSE Driver The firmware does *NOT* contain the bootloader, so the ability to det to dfu mode should not be altered or impeded by what you flashed . . . UNQUOTE Thanks Tim, but the scenario I was proposing was not that the firmware contained the bootloader, but that the nboot1 bit controls where in memory the processor goes to find boot code or an address to boot from, depending on what is stored in the location and how the fw responds to the data.? As I read it if a fw load has a different value for nboot1 than the original code, the machine will not boot as intended. Whether this is my problem or not is unknown, but it seems that the value that a fw load sets the nboot1 bit at could change boot operations. |
|
Re: New Problem (Bricked?) Re: Trouble Setting Up DFuSE Driver
QUOTE
toggle quoted message
Show quoted text
-----Original Message-----
From: [email protected] <[email protected]> On Behalf Of Tim Dawson Sent: Tuesday, January 24, 2023 12:03 AM To: [email protected] Subject: Re: [nanovna-users] New Problem (Bricked?) Re: Trouble Setting Up DFuSE Driver The firmware does *NOT* contain the bootloader, so the ability to det to dfu mode should not be altered or impeded by what you flashed . . . UNQUOTE Thanks Tim, but the scenario I was proposing was not that the firmware contained the bootloader, but that the nboot1 bit controls where in memory the processor goes to find boot code or an address to boot from, depending on what is stored in the location and how the fw responds to the data. As I read it if a fw load has a different value for nboot1 than the original code, the machine will not boot as intended. Whether this is my problem or not is unknown, but it seems that the value that a fw load sets the nboot1 bit at could change boot operations. |
|
Re: New Problem (Bricked?) Re: Trouble Setting Up DFuSE Driver
The firmware does *NOT* contain the bootloader, so the ability to det to dfu mode should not be altered or impeded by what you flashed . . .
toggle quoted message
Show quoted text
On January 23, 2023 10:34:59 PM CST, Al Waschka <awaschka@...> wrote:
The time from working with the original fw load and not identifying as a DFU unit was literally minutes, on the same cable, computer, software and drivers. --
Sent from my Android device with K-9 Mail. Please excuse my brevity. |
|
Re: New Problem (Bricked?) Re: Trouble Setting Up DFuSE Driver
The time from working with the original fw load and not identifying as a DFU unit was literally minutes, on the same cable, computer, software and drivers.
The Version Page of the hardware with its original fw load said it was a NanoVNA-H Version 1;1 Build Time Dec 21 2021 13:46:37. I bought it as a NanoVNA, not an -H model, so IDK what it actually was. Apparently it was a clone, at least according to one post I saw which mentioned the omission of the "CH0" designation on the front panel as an indication. I only reloaded DfuSe and the driver when I couldn't get the hardware to show up at all when I put it in DFU mode (or thought I did) by pressing the jogwheel when powering up. I got the white screen which is supposed to indicate DFU mode. When none of that worked I used the hardware method of shorting the Vcc test point to the Boot0 test point When I powered up I got the white screen. Unfortunately the computer did not recognize the unit when I plugged it in. The NanoVNA User Guide contains a schematic. The Boot0 pin (which is set to 1 when it is shorted to Vcc, along with two programmable bits, control which portion of memory is selected during boot. So if different fw loads control those two programmable bits differently, it would seem possible that a fw load could change how the hardware boots up and also casts some doubt on the prevalent opinion that the boot code is controlled by separate hardware, making the units "unbrickable". This is just my assessment as a retired engineer reading schematics and chip data manuals, and may not be correct. I am running a current version of Windows 10, so not W11. |
|
Re: New Problem (Bricked?) Re: Trouble Setting Up DFuSE Driver
I would first try a new cable. Often issues like this are caused by an intermittent cable or connector. Really, even if that cable often works, and works for charging. If you are using a usb-hub separate from your computer, don't: plug it directly into your computer's usb port. I truly hope this helps you see the device connect in DFU mode (seen in Device Manager under the USB Hubs item).
- You should not have had to reinstall the driver that just worked for you earlier today - the computer won't change the installed driver by itself, so I hope you didn't somehow make it worse by trying to reinstall the driver. - The nanovna-H will have a white screen when it is in DFU mode. - You cannot brick a nanovna with a firmware update - the DFU bootloader is built into the hardware. - You should download firmware from this link, it is much newer, is very stable, and has many new features compared to the 2019 firmware you tried: (scroll to the bottom, select the file named NanoVNA.H.v1.2.00.dfu Don't try other newer versions until you get this one running correctly. - Are you running Windows11? Most of us have limited experience in dealing with any weird behavior using Win11 - if so, you may want to try a Win10 machine to see if your problem goes away. Another tactic: many have found that downloading / running NanoVNA-app, which has a menu item to update the nanovna firmware, avoids some issues - but it still requires the driver to be in place (which was indeed in place since you earlier updated your device). |
|
Re: New Problem (Bricked?) Re: Trouble Setting Up DFuSE Driver
Thanks, but when I set it to DFU mode by holding down the jogwheel or by shorting the VCC to Boot lands, each at power up, it doesn¡¯t show up in device manager at all. The computer, which detected it earlier today before I changed the fw, doesn't react when it is plugged into the USB port.
toggle quoted message
Show quoted text
The computer did not detect the USB comm port before, or now. In both cases the device shows up as an unknown USB device and will not accept a driver update. -----Original Message-----
From: [email protected] <[email protected]> On Behalf Of Chris Gardner via groups.io Sent: Monday, January 23, 2023 7:00 PM To: [email protected] Subject: Re: [nanovna-users] New Problem (Bricked?) Re: Trouble Setting Up DFuSE Driver Greetings, It is important to understand that the NanoVna shows up two different ways depending whether it is in DFU mode, or normal operating mode. In normal mode, it grabs a Comm Port. In DFU mode, it will be listed (under a different category in device manager) as one of the USB hub devices On Jan 23, 2023, at 18:23, Al Waschka <awaschka@...> wrote: |
|
Re: New Problem (Bricked?) Re: Trouble Setting Up DFuSE Driver
Greetings, It is important to understand that the NanoVna shows up two different ways depending whether it is in DFU mode, or normal operating mode. In normal mode, it grabs a Comm Port. In DFU mode, it will be listed (under a different category in device manager) as one of the USB hub devices
toggle quoted message
Show quoted text
On Jan 23, 2023, at 18:23, Al Waschka <awaschka@...> wrote: |
|
New Problem (Bricked?) Re: Trouble Setting Up DFuSE Driver
Apparently you can brick one of these, even with a recommended firmware upload.
As previously noted, I was able to get DFuSe to recognize the unit and uploaded the 800MHz firmware, which the NanoVNA.com site recommended as being more stable. The firmware operates, but is missing the CONFIG option. I found several things I didn't like in the version and set about trying to upload a different version. I tried the jogwheel press while powering on and got a white screen which is supposed to indicate that the unit is in DFU mode. When I plugged it in, the computer didn't recognize it. I thought maybe I needed to do the hardware boot option so I shorted the Vcc and Boot terminals as recommenced and when I powered up I got the same white screen, but still no recognition when I plugged the unit in to the computer. I reinstalled the driver which had worked before, but still no recognition that the unit is being plugged in. Help. Please! |
|
Re: Trouble Setting Up DFuSE Driver
Well, I followed the directions, but when my indications didn't agree I quit reading. I finally realized (from the "you can¡¯t brick it" note that the designation of STM Bootloader was correct. I had to go to the DFuSe folder and manually install the correct driver. I now have it working in DFU mode.
toggle quoted message
Show quoted text
On to trying to get the normal mode to work properly...... -----Original Message-----
From: [email protected] <[email protected]> On Behalf Of Al Waschka Sent: Monday, January 23, 2023 1:35 PM To: [email protected] Subject: Re: [nanovna-users] Trouble Setting Up DFuSE Driver Thanks for trying to help, but I think I followed the directions in the link explicitly. Comments below marked <<<<<xxxxx>>>>>> -----Original Message----- From: [email protected] <[email protected]> On Behalf Of HA3HZ Sent: Monday, January 23, 2023 1:00 PM To: [email protected] Subject: Re: [nanovna-users] Trouble Setting Up DFuSE Driver The description of the steps means to me that you are not aware that in 'normal' operation, when the device communicates with the PC, you need a driver called VCP. <<<<<<The first thing I did was to install the virtual comm port driver, as suggested in the link you sent me.>>>>>> When you are in so-called DFU (device firmware upgrade) mode, you need another driver, which is automatically installed by the program when DfuSe is installed for the first time. Now we just need the dfu driver. <<<<<<When I installed DFuSe, no driver was installed for the device. >>>>>>> If for some reason this does not happen, or you have installed something and the PC accepts it - but you still cannot connect. Then you need the help of USBDeview. (search google: www.nirsoft.net) This small program without installation shows you which USB device you have connected since the installation of your operating system. Shows the drivers. You can delete what may cause the collision with the right mouse button pointing to the row. If several USB devices are connected, they are marked with a green line. Choose which one could be at fault. Be careful not to delete the necessary device from the queue. <<<<<<<I have repeatedly uninstalled the devices (operate mode and DFU mode) in Device manager to no avail.>>>>>> <<<<<<<In DFU mode it is identifying as an STM Bootloader and will not allow driver update. Does the firmware provide a device identity to Windows which then specifies the appropriate driver? Where is the STM Bootloader ID coming from?>>>>>>> After deleting, remove the device (which is in DFU mode) and you will find the win10 driver in the driver folder at the DefuSE installation location. Install this driver. Plug in the device that is still in DFU mode. USBDeview shows it in green. After that, the DefUSE demo will already see the device in dfu mode. If you accidentally uploaded an incorrect or incorrect dfu file, the device will remain in dfu mode. If you can't login in normal mode, then don't panic either, just find the working dfu file and repeat the installation. After the installation, the device will log in normally by restarting (off - on). I was long, if something is not clear, please ask or read on my website. -- Gyula HA3HZ ( ) |
|
Re: Trouble Setting Up DFuSE Driver
Thanks for trying to help, but I think I followed the directions in the link explicitly. Comments below marked <<<<<xxxxx>>>>>>
toggle quoted message
Show quoted text
-----Original Message-----
From: [email protected] <[email protected]> On Behalf Of HA3HZ Sent: Monday, January 23, 2023 1:00 PM To: [email protected] Subject: Re: [nanovna-users] Trouble Setting Up DFuSE Driver The description of the steps means to me that you are not aware that in 'normal' operation, when the device communicates with the PC, you need a driver called VCP. <<<<<<The first thing I did was to install the virtual comm port driver, as suggested in the link you sent me.>>>>>> When you are in so-called DFU (device firmware upgrade) mode, you need another driver, which is automatically installed by the program when DfuSe is installed for the first time. Now we just need the dfu driver. <<<<<<When I installed DFuSe, no driver was installed for the device. >>>>>>> If for some reason this does not happen, or you have installed something and the PC accepts it - but you still cannot connect. Then you need the help of USBDeview. (search google: www.nirsoft.net) This small program without installation shows you which USB device you have connected since the installation of your operating system. Shows the drivers. You can delete what may cause the collision with the right mouse button pointing to the row. If several USB devices are connected, they are marked with a green line. Choose which one could be at fault. Be careful not to delete the necessary device from the queue. <<<<<<<I have repeatedly uninstalled the devices (operate mode and DFU mode) in Device manager to no avail.>>>>>> <<<<<<<In DFU mode it is identifying as an STM Bootloader and will not allow driver update. Does the firmware provide a device identity to Windows which then specifies the appropriate driver? Where is the STM Bootloader ID coming from?>>>>>>> After deleting, remove the device (which is in DFU mode) and you will find the win10 driver in the driver folder at the DefuSE installation location. Install this driver. Plug in the device that is still in DFU mode. USBDeview shows it in green. After that, the DefUSE demo will already see the device in dfu mode. If you accidentally uploaded an incorrect or incorrect dfu file, the device will remain in dfu mode. If you can't login in normal mode, then don't panic either, just find the working dfu file and repeat the installation. After the installation, the device will log in normally by restarting (off - on). I was long, if something is not clear, please ask or read on my website. -- Gyula HA3HZ ( ) |
HA3HZ
Jim Allyn - N7JA
Igor - PY3IG
to navigate to use esc to dismiss