Hello Folks,

Saw couple topics related with "USB device (device descriptor request failed)" on this group, at least two of them - similar to what I'm facing right now - seems to have no solution. When trying to put my NanoVNA H4 in DFU mode (click the wheel + power on), Windows 10 would show it under device manager as "USB device (device descriptor request failed)". Other than trying to upgrade firmware, the device seems to be working properly.

Tried unsuccessfully couple solutions found here and there:

- Right clicked "USB device (device descriptor request failed)" and point to installation folders of "DfuSe Demo V3.0.6" and "STM32 Cube Programmer 2.16.0", trying to discover DFU drivers
- Excluded "USB device (device descriptor request failed)" from USB power saving
- Entered DFU from NanoVNA H4 advanced configuration menu; entered DFU mode by shunting the BOOT0 and the adjacent VDD pins
- Also tried on macOS and Linux...

The NanoVNA H4 seems to have no problem entering DFU using one of available modes to do so, but somehow, once in that mode, wrongly presenting himself to OS. I believe during the last firmware upgrade some part of the NanoVNA H4 has been wiped / wrongly flashed etc..., ruining the USB flashing interface.

While further googling this issue, I found "nanoVNA-H – recovery" (https://owenduffy.net/blog/?p=16699) that describes a procedure to flash NanoVNA H, using SWD interface. Such procedure consist in connecting an external STM32 programer (STLINK-V3SET) to the pins SWDIO, SWCLK, GND and NRST present in both NanoVNA H and H4.

Did anyone tried recovering NanoVNA H/H4 from this issue using STM32 programmer?

(sorry for the long post, just want to be clear on my ask)

Regards,
Anaxi

Flashing with stlink will always work. It's no different than flashing a
stm32 developer board.

On Wed, 24 Apr 2024, 12:32 Anaxi via groups.io, <anxanywhere=
gmail.com@groups.io> wrote:

Hello Folks,

Saw couple topics related with "USB device (device descriptor request
failed)" on this group, at least two of them - similar to what I'm facing
right now - seems to have no solution. When trying to put my NanoVNA H4 in
DFU mode (click the wheel + power on), Windows 10 would show it under
device manager as "USB device (device descriptor request failed)". Other
than trying to upgrade firmware, the device seems to be working properly.

Tried unsuccessfully couple solutions found here and there:

- Right clicked "USB device (device descriptor request failed)"
and point to installation folders of "DfuSe Demo V3.0.6" and "STM32 Cube
Programmer 2.16.0", trying to discover DFU drivers
- Excluded "USB device (device descriptor request failed)" from
USB power saving
- Entered DFU from NanoVNA H4 advanced configuration menu; entered
DFU mode by shunting the BOOT0 and the adjacent VDD pins
- Also tried on macOS and Linux...

The NanoVNA H4 seems to have no problem entering DFU using one of
available modes to do so, but somehow, once in that mode, wrongly
presenting himself to OS. I believe during the last firmware upgrade some
part of the NanoVNA H4 has been wiped / wrongly flashed etc..., ruining the
USB flashing interface.

While further googling this issue, I found "nanoVNA-H – recovery" (
https://owenduffy.net/blog/?p=16699) that describes a procedure to flash
NanoVNA H, using SWD interface. Such procedure consist in connecting an
external STM32 programer (STLINK-V3SET) to the pins SWDIO, SWCLK, GND and
NRST present in both NanoVNA H and H4.

Did anyone tried recovering NanoVNA H/H4 from this issue using STM32
programmer?

(sorry for the long post, just want to be clear on my ask)

Regards,
Anaxi

Hi Dragan,

Wondering if after that I will be able to flash via USB again?

Anaxi

Hi Anaxi,

I had a problem updating my Nano VNA H4 firmware the other day, I tried
using Dfu_Demo and STM32CubeProgrammer neither of which worked, after one
attempt it even stopped the screen working completley but it still
wrnt into DFU mode when being powered on, I even tried NanoVNA -App and
that also failed, eventuallt I found this artical Updating the NanoVNA
Firmware – Ripples in the Ether (nt7s.com)
<https://nt7s.com/2019/11/updating-the-nanovna-firmware/> followed the
instructions and it worked, firmware updated and screen back to normal,
recakibrated everything and all is good. One slight bit of confusion
dfu-util showed me two devices, which I eventuall worked, it was treating
the internal memory and the SD card as two separate devices, I selected the
"Internal Flash" as the target and it worked. Zadig did spend a few minutes
updating the drivers or at least it said it did, I didn't check version
numbers before and after.

After trying this I did not try DFU_Demo or STM32CubeProgrammer again so
cannot say I if Zadig alone will fix the problem but I have also read
somewhere that there is a problem with STM32CubeProgrammer v2.16 not
recognising drivers and that going back to v2.15 does work.

Good luck.

David Pryor

DFU mode is a feature of the firmware so if your hypothesis is correct
(firmware issue) this would resolve it. I doubt that is the case since it
is recognized by the OS. I would try with Linux again and post the error
that you get.

On Wed, 24 Apr 2024, 15:27 Anaxi via groups.io, <anxanywhere=
gmail.com@groups.io> wrote:

Hi Dragan,

Wondering if after that I will be able to flash via USB again?

Anaxi

Hi Dagan,

Right now, none of the OS recognizes my NanoVNA H4... electrically, there is some presence, but when it comes to USB enumerating a device, it fails everywhere (macOS, Windows and Linux). I'll try to capture Linux logs while trying to detect this device in DFU mode...

Anaxi

dmesg -w in the console then plug in the device. That should be enough to
figure out what is going on. Make sure that you are using the supplied USB
cable or one that you are sure it works as data cable.

On Wed, 24 Apr 2024, 19:12 Anaxi via groups.io, <anxanywhere=
gmail.com@groups.io> wrote:

Hi Dagan,

Right now, none of the OS recognizes my NanoVNA H4... electrically, there
is some presence, but when it comes to USB enumerating a device, it fails
everywhere (macOS, Windows and Linux). I'll try to capture Linux logs while
trying to detect this device in DFU mode...

Anaxi

Hi Dagan,

See the attached dmesg output screen capture (I was using ubuntu live CD).

In summary:

usb usbi-port3: unable to enumerate USB device

ANx

same thing yesterdsay. Went to update to 1.2.27 and all 3 windows computers recognised as a port but not the dFU port, tried even shorting the contacts for DFU mode.
in the end last ditch removed battery, pushed buttons, reconnect battery and it was recognised fine. Weird.
Good luck.

Hi Maxwelloau,

Can you share more details on:

“removed battery, pushed buttons, reconnect battery and it was recognised”

After removing the battery, how long the battery was disconnected? which button you pushed and for how long?

Anaxi

If it recognizes the device as a serial port in normal mode then your
hypothesis is probably right. Order an stlink clone from AliExpress or eBay
and flash the firmware that way.

On Wed, 24 Apr 2024, 22:54 Anaxi via groups.io, <anxanywhere=
gmail.com@groups.io> wrote:

Hi Dagan,

See the attached dmesg output screen capture (I was using ubuntu live CD).

In summary:

usb usbi-port3: unable to enumerate USB device

ANx

Same behavior when connected in normal mode… ordered stm32 programmer, should arrive in 4 days

Let us all know if it solves the issue...

On Thu, 25 Apr 2024, 10:53 Anaxi via groups.io, <anxanywhere=
gmail.com@groups.io> wrote:

Same behavior when connected in normal mode… ordered stm32 programmer,
should arrive in 4 days

Well... got the STM32 programmer today...

- I was able to update firmware to 1.2.29
- But still, both norma and DFU, are not recognised by OS (Windows, Linux and macOS)

Sad Anaxi :(

If everything works, except USB communication, then it has to be a hardware
issue.

On Sat, 27 Apr 2024, 03:38 Anaxi via groups.io, <anxanywhere=
gmail.com@groups.io> wrote:

Well... got the STM32 programmer today...

- I was able to update firmware to 1.2.29
- But still, both norma and DFU, are not recognised by OS
(Windows, Linux and macOS)

Sad Anaxi :(

DFU mode comm is *NOT* a part of the downloadable software - it is part of the embedded bootloader.

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

While on STM32CubeProgrammer, you can access/modify Option Bytes and among available options, you can find nBoot1 that will dictate if DFU mode should boot from flash area or SRAM... I was hopping that it could be related to this...

Good news :)

Disconnecting the battery for long period (this case was about 12h) solved the problem.