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 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.
