Hi friends,

I have a V2Plus4 device bought from the NanoRFE official store on Aliexpress.

Back when I received the device, it was working perfectly.

Several months ago, it started to crash when I tried to save calibration data, presenting the following error message on its screen:

SN: 35557E54-00043333-35343234
xtal freq 24.000 MHz
touch cal:
1977. 1945
-61. -91
debug0 2.12
debug1 18.37
BBGAIN 0: 0.00 dB
BBGAIN 1: -5.62 dB
BBGAIN 2: -14.56 dB
BBGAIN 3: -26.51 dB
flash_program_data: write error: flash status 36
save caldata 0. ret = -2
src magic: 8008123B, dst magic = 0

Still, there were no other issues. The only drawback was that I was not able to save calibration data, but otherwise the device was working perfectly, both when operating via screen or via a computer plugged to USB. I tried to save calibration data a few times (on different days) to see whether it would magically get back to work, to no avail. But fortunately I could just reboot the device after the error was presented and get back to use it, otherwise, as normal.

Please note I don't know if the situation above is related with the issue I'm experiencing now. I mentioned it just in case.

Then, I spent some months without using the device.

Last week, I finally found myself in need to use the device, then I plugged it to USB, waited for the battery to charge to 3 points and tried to power it up (still connected to USB). It wouldn't work: the device would show only a white screen, and the computer's dmesg would present an USB enumeration error:

[ 6773.642859] usb 2-3.4: new full-speed USB device number 8 using xhci_hcd
[ 6773.715984] usb 2-3.4: device descriptor read/64, error -32
[ 6773.896352] usb 2-3.4: device descriptor read/64, error -32
[ 6774.076329] usb 2-3.4: new full-speed USB device number 9 using xhci_hcd
[ 6774.149322] usb 2-3.4: device descriptor read/64, error -32
[ 6774.329318] usb 2-3.4: device descriptor read/64, error -32
[ 6774.436696] usb 2-3-port4: attempt power cycle
[ 6775.029652] usb 2-3.4: new full-speed USB device number 10 using xhci_hcd
[ 6775.029784] usb 2-3.4: Device not responding to setup address.
[ 6775.236403] usb 2-3.4: Device not responding to setup address.
[ 6775.443128] usb 2-3.4: device not accepting address 10, error -71
[ 6775.516283] usb 2-3.4: new full-speed USB device number 11 using xhci_hcd
[ 6775.516399] usb 2-3.4: Device not responding to setup address.
[ 6775.722749] usb 2-3.4: Device not responding to setup address.
[ 6775.929611] usb 2-3.4: device not accepting address 11, error -71
[ 6775.929829] usb 2-3-port4: unable to enumerate USB device

Well, now the situation gets weird.

Yesterday, I transported the device from home to the university because I wanted to test with another USB-B cable but I had no other cable at home.

I was talking to other people about what happened to the device and tried to power it up to show them the white screen. It magically came back to life! We powered if off and on a few times. We transported the device between rooms and it didn't stop working. We even measured some antennas. I tried to save the calibration data to see if the issue persisted - yes, it would still crash with the "write error" message. But I was still able to reboot the device and use it, otherwise, as normal. We plugged it to USB, and it was recognized by the computer and worked perfectly.

Then, I transported the device back to home, trying to be careful not to shake it too much. When I arrived home, I immediately tried to power it on to see if it was still working. Sadly, it was dead again: white screen and USB enumeration error.

I thought maybe there was some bad connection, so I opened the case to visually inspect the device under the microscope, but I found nothing odd:

I tried to reseat the display, and to unplug and plug again to USB several times, but the same symptoms persist.

Do you have any ideas on how I should proceed debugging the device?

Also, can someone who owns a V2Plus4 please confirm if the NanoVNA should be recognized via USB if it is powered up without the screen module? If yes, then perhaps I can rule out an issue with the screen module.

Should I try to measure GD32 pin 5 to see if it is being clocked?

Should I try to heat the GD32 to rule out cold solder?

Any ideas are appreciated.

Thank you and best regards,
Paulo Matias

Just an addendum: I bought on November 2020 from the "Official store on Aliexpress" link which used to exist on NanoRFE website (https://web.archive.org/web/20201115193335/https://nanorfe.com/nanovna-v2.html).

Are you using the same cable and computer at home that failed before, Paulo?
Or maybe you brought a different cable from the university?

If it is the same cable then it seems to me that that cable - or the USB
port on your computer - is faulty.
You should borrow the working cable from the uni and maybe try a different
USB port on your computer.
You will see my dmesg below : Debian 11.7 :

[ 245.233859] usb 5-1: new full-speed USB device number 2 using uhci_hcd
[ 245.423015] usb 5-1: New USB device found, idVendor=04b4,
idProduct=0008, bcdDevice= 0.01
[ 245.423026] usb 5-1: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
[ 245.423031] usb 5-1: Product: You just lost the game.
[ 245.423036] usb 5-1: Manufacturer: The game
[ 245.423040] usb 5-1: SerialNumber: You just lost the game.
[ 245.624965] cdc_acm 5-1:1.0: ttyACM0: USB ACM device
[ 245.627438] usbcore: registered new interface driver cdc_acm
[ 245.627440] cdc_acm: USB Abstract Control Model driver for USB modems
and ISDN adapters

Dave, G1OGY


On Thu, 3 Aug 2023 at 17:30, <syscoder@gmail.com> wrote:

> Hi friends,
>
> I have a V2Plus4 device bought from the NanoRFE official store on
> Aliexpress.
>
> Back when I received the device, it was working perfectly.
>
> Several months ago, it started to crash when I tried to save calibration
> data, presenting the following error message on its screen:
>
> SN: 35557E54-00043333-35343234
> xtal freq 24.000 MHz
> touch cal:
> 1977. 1945
> -61. -91
> debug0 2.12
> debug1 18.37
> BBGAIN 0: 0.00 dB
> BBGAIN 1: -5.62 dB
> BBGAIN 2: -14.56 dB
> BBGAIN 3: -26.51 dB
> flash_program_data: write error: flash status 36
> save caldata 0. ret = -2
> src magic: 8008123B, dst magic = 0
>
> Still, there were no other issues. The only drawback was that I was not
> able to save calibration data, but otherwise the device was working
> perfectly, both when operating via screen or via a computer plugged to USB.
> I tried to save calibration data a few times (on different days) to see
> whether it would magically get back to work, to no avail. But fortunately I
> could just reboot the device after the error was presented and get back to
> use it, otherwise, as normal.
>
> Please note I don't know if the situation above is related with the issue
> I'm experiencing now. I mentioned it just in case.
>
> Then, I spent some months without using the device.
>
> Last week, I finally found myself in need to use the device, then I
> plugged it to USB, waited for the battery to charge to 3 points and tried
> to power it up (still connected to USB). It wouldn't work: the device would
> show only a white screen, and the computer's dmesg would present an USB
> enumeration error:
>
> [ 6773.642859] usb 2-3.4: new full-speed USB device number 8 using xhci_hcd
> [ 6773.715984] usb 2-3.4: device descriptor read/64, error -32
> [ 6773.896352] usb 2-3.4: device descriptor read/64, error -32
> [ 6774.076329] usb 2-3.4: new full-speed USB device number 9 using xhci_hcd
> [ 6774.149322] usb 2-3.4: device descriptor read/64, error -32
> [ 6774.329318] usb 2-3.4: device descriptor read/64, error -32
> [ 6774.436696] usb 2-3-port4: attempt power cycle
> [ 6775.029652] usb 2-3.4: new full-speed USB device number 10 using
> xhci_hcd
> [ 6775.029784] usb 2-3.4: Device not responding to setup address.
> [ 6775.236403] usb 2-3.4: Device not responding to setup address.
> [ 6775.443128] usb 2-3.4: device not accepting address 10, error -71
> [ 6775.516283] usb 2-3.4: new full-speed USB device number 11 using
> xhci_hcd
> [ 6775.516399] usb 2-3.4: Device not responding to setup address.
> [ 6775.722749] usb 2-3.4: Device not responding to setup address.
> [ 6775.929611] usb 2-3.4: device not accepting address 11, error -71
> [ 6775.929829] usb 2-3-port4: unable to enumerate USB device
>
> Well, now the situation gets weird.
>
> Yesterday, I transported the device from home to the university because I
> wanted to test with another USB-B cable but I had no other cable at home.
>
> I was talking to other people about what happened to the device and tried
> to power it up to show them the white screen. It magically came back to
> life! We powered if off and on a few times. We transported the device
> between rooms and it didn't stop working. We even measured some antennas. I
> tried to save the calibration data to see if the issue persisted - yes, it
> would still crash with the "write error" message. But I was still able to
> reboot the device and use it, otherwise, as normal. We plugged it to USB,
> and it was recognized by the computer and worked perfectly.
>
> Then, I transported the device back to home, trying to be careful not to
> shake it too much. When I arrived home, I immediately tried to power it on
> to see if it was still working. Sadly, it was dead again: white screen and
> USB enumeration error.
>
> I thought maybe there was some bad connection, so I opened the case to
> visually inspect the device under the microscope, but I found nothing odd:
>
>
>
>
>
> I tried to reseat the display, and to unplug and plug again to USB several
> times, but the same symptoms persist.
>
> Do you have any ideas on how I should proceed debugging the device?
>
> Also, can someone who owns a V2Plus4 please confirm if the NanoVNA should
> be recognized via USB if it is powered up without the screen module? If
> yes, then perhaps I can rule out an issue with the screen module.
>
> Should I try to measure GD32 pin 5 to see if it is being clocked?
>
> Should I try to heat the GD32 to rule out cold solder?
>
> Any ideas are appreciated.
>
>
> Thank you and best regards,
> Paulo Matias
>
>
>

Hi Dave,

Thank you for the reply.

Yes, I was using the same cable that failed at home before. It is a blue cable which came with the NanoVNA when I bought it, and it's pretty different from the ones at uni, so I'm pretty sure I didn't switch cables.

Already on the first time it died, I tested with 3 different computers, same enumeration errors on all of them.

Today, I also brought home 4 USB cables from uni. Same errors using any of them.

I also tried to enter bootloader by pressing the "left" button while turning the device on. I get the same enumeration errors.

Let me just stress out the day it came back to life (with screen working and all), it was also recognized via USB (using the original cable which came with the device) by cdc_acm, just like your dmesg. But when I brought it back home and it died again (white screen), USB also started to present enumeration errors again.

Therefore, I'm very suspicious the GD32 MCU isn't booting up correctly.

Best regards,
Paulo Matias

Hello Paulo
I tried to replicate your problem.
Note that my nanoVNA is a 4-plus and it (still) has the original
firmware: 20201013.

Withoutthe USB cable connected I find that when I hold down the "left"
button (the one closest to the power switch) I get a `white` screen,
no text.
Could it be that `something` is holding the "left" button down; either
physically (the case, perhaps) or `electrically` (some minor short)?

Dave, G1OGY

On Sat, 5 Aug 2023 at 05:59, <syscoder@gmail.com> wrote:

>
> Hi Dave,
>
> Thank you for the reply.
>
> Yes, I was using the same cable that failed at home before. It is a blue cable which came with the NanoVNA when I bought it, and it's pretty different from the ones at uni, so I'm pretty sure I didn't switch cables.
>
> Already on the first time it died, I tested with 3 different computers, same enumeration errors on all of them.
>
> Today, I also brought home 4 USB cables from uni. Same errors using any of them.
>
> I also tried to enter bootloader by pressing the "left" button while turning the device on. I get the same enumeration errors.
>
> Let me just stress out the day it came back to life (with screen working and all), it was also recognized via USB (using the original cable which came with the device) by cdc_acm, just like your dmesg. But when I brought it back home and it died again (white screen), USB also started to present enumeration errors again.
>
> Therefore, I'm very suspicious the GD32 MCU isn't booting up correctly.
>
> Best regards,
> Paulo Matias
>

Also touch screen activated (touched) when switch on gives a white screen

So a mechanical mooved screen pressing from inside to the case could also
cause a white-out..

Dg9bfc sigi



Am 05.08.2023 15:49 schrieb "Dave (G1OGY)" <g1ogy@g1ogy.com>:

> Hello Paulo
> I tried to replicate your problem.
> Note that my nanoVNA is a 4-plus and it (still) has the original
> firmware: 20201013.
>
> Withoutthe USB cable connected I find that when I hold down the "left"
> button (the one closest to the power switch) I get a `white` screen,
> no text.
> Could it be that `something` is holding the "left" button down; either
> physically (the case, perhaps) or `electrically` (some minor short)?
>
> Dave, G1OGY
>
> On Sat, 5 Aug 2023 at 05:59, <syscoder@gmail.com> wrote:
> >
> > Hi Dave,
> >
> > Thank you for the reply.
> >
> > Yes, I was using the same cable that failed at home before. It is a blue
cable which came with the NanoVNA when I bought it, and it's pretty different
from the ones at uni, so I'm pretty sure I didn't switch cables.
> >
> > Already on the first time it died, I tested with 3 different computers,
same enumeration errors on all of them.
> >
> > Today, I also brought home 4 USB cables from uni. Same errors using any
of them.
> >
> > I also tried to enter bootloader by pressing the "left" button while
turning the device on. I get the same enumeration errors.
> >
> > Let me just stress out the day it came back to life (with screen working
and all), it was also recognized via USB (using the original cable which came
with the device) by cdc_acm, just like your dmesg. But when I brought it back
home and it died again (white screen), USB also started to present enumeration
errors again.
> >
> > Therefore, I'm very suspicious the GD32 MCU isn't booting up correctly.
> >
> > Best regards,
> > Paulo Matias
> >
>
>
>
>
>
>



_._,_._,_

* * *

Hi Dave,

I have measured the left button under the oscilloscope (please see the images below). It is pulled up to 3V by the MCU as expected and pretty stable. I have also checked that if I press the button, voltage goes down to zero as expected. So perhaps, a button issue is ruled out.

(I know, the schematics are for 2.2, but this part of the circuit looks the same on V2Plus4).

Best regards,
Paulo Matias

Hi all,

Since the oscilloscope was at bench, I took the opportunity to measure some test points to try to make some sense of what's happening.

First, I measured display SPI, as below.

All three terminals (SDO, SCK and SDI) were constantly at ground.

I tried to set the oscilloscope to trigger on rising edge at level 1.5V on SINGLE SEQ mode. No signal spotted on any of SDO, SCK or SDI. Tried to boot up the NanoVNA several times with probe in place.

Next, I tried to measure Si5351 I2C, as below.

Both SDA and SCL were constantly at Vdd=3V.

I tried to set the oscilloscope to trigger on falling edge at level 1.5V on SINGLE SEQ mode. No signal spotted on any of SDA or SCL. Tried to boot up the NanoVNA several times with probe in place.

Finally, I tried to measure GD32 clock input, as below.

Well, at least the GD32 seems like it is being clocked. Please see the signal below.

Since there is no SPI or I2C activity at all, it seems like the GD32 MCU simply isn't running any code.

However, it is being clocked.

And its Vdd is stable at 3V (I measured pin 48 with trigger on falling edge at level 2.7V on SINGLE SEQ mode, and there were no drops once the NanoVNA was turned on).

So what could been happening?

If the GD32 had died, it wouldn't have magically revived this week, only to die again.

Maybe it's cold solder?

Do you have any ideas of other test points I should measure?

Best regards,
Paulo Matias

Hi Siegfried,

Thank you for your hypothesis. I have just tested it. I have measured LCD−IRQ (at CONN303) under the oscilloscope and it's high. It only goes to low when I press the screen. Therefore, touch screen is not constantly pressed.

Going further on possible test points, I measured (also at CONN303):

T−CS (connected to GD32 PB7, xpt2046_cs): constantly low (even over reboots)
LCD−DC (connected to GD32 PB6, ili9341_dc): constantly low (even over reboots)
LCD−CS (connected to GD32 PA15, ili9341_cs): constantly high once the device is powered

Looking at https://github.com/nanovna-v2/NanoVNA2-firmware/blob/master/board_v2_plus4/board.hpp#L61-L63 and https://github.com/nanovna-v2/NanoVNA2-firmware/blob/master/board_v2_plus4/board.cpp#L206-L229 , we can see all above are set as outputs in the first routine which runs once the firmware starts (assuming not much in this regard have been changed in the proprietary firmware).

T−CS and LCD−CS are also set as high in the same routine.

However, T−CS is measured as low. Let me stress out I set the oscilloscope to trigger on rising edge at level 1.5V and put it in SINGLE SEQ mode while the NanoVNA was being powered up. Another evidence firmware is not starting to run.

Any ideas? Should I proceed to try heating the GD32 up? Or a cold solder could be elsewhere?

Best regards,
Paulo Matias

Maybe the processor is stuck in Reset? Is there a reset pin you can check?

Am 06.08.23 um 06:50 schrieb syscoder@gmail.com:

> Hi all,
>
> Since the oscilloscope was at bench, I took the opportunity to measure
> some test points to try to make some sense of what's happening.
>
> First, I measured display SPI, as below.
>
>
>
>
>
> All three terminals (SDO, SCK and SDI) were constantly at ground.
>
> I tried to set the oscilloscope to trigger on rising edge at level 1.5V
> on SINGLE SEQ mode. No signal spotted on any of SDO, SCK or SDI. Tried
> to boot up the NanoVNA several times with probe in place.
>
> Next, I tried to measure Si5351 I2C, as below.
>
>
>
>
>
>
> Both SDA and SCL were constantly at Vdd=3V.
>
> I tried to set the oscilloscope to trigger on falling edge at level 1.5V
> on SINGLE SEQ mode. No signal spotted on any of SDA or SCL. Tried to
> boot up the NanoVNA several times with probe in place.
>
> Finally, I tried to measure GD32 clock input, as below.
>
>
>
>
>
> Well, at least the GD32 seems like it is being clocked. Please see the
> signal below.
>
>
>
> Since there is no SPI or I2C activity at all, it seems like the GD32 MCU
> simply isn't running any code.
>
> However, it is being clocked.
>
> And its Vdd is stable at 3V (I measured pin 48 with trigger on falling
> edge at level 2.7V on SINGLE SEQ mode, and there were no drops once the
> NanoVNA was turned on).
>
> So what could been happening?
>
> If the GD32 had died, it wouldn't have magically revived this week, only
> to die again.
>
> Maybe it's cold solder?
>
> Do you have any ideas of other test points I should measure?
>
> Best regards,
> Paulo Matias
>

i had a white out with a not well seated ribbon cable on display and one
from mechanical pressure on touch panel

both checked?? (unplug and replug sometimes helps)

dg9bfc sigi

Am 06.08.2023 um 06:50 schrieb syscoder@gmail.com:

> Hi all,
>
> Since the oscilloscope was at bench, I took the opportunity to measure
> some test points to try to make some sense of what's happening.
>
> First, I measured display SPI, as below.
>
>
>
>
>
> All three terminals (SDO, SCK and SDI) were constantly at ground.
>
> I tried to set the oscilloscope to trigger on rising edge at level
> 1.5V on SINGLE SEQ mode. No signal spotted on any of SDO, SCK or SDI.
> Tried to boot up the NanoVNA several times with probe in place.
>
> Next, I tried to measure Si5351 I2C, as below.
>
>
>
>
>
>
> Both SDA and SCL were constantly at Vdd=3V.
>
> I tried to set the oscilloscope to trigger on falling edge at level
> 1.5V on SINGLE SEQ mode. No signal spotted on any of SDA or SCL. Tried
> to boot up the NanoVNA several times with probe in place.
>
> Finally, I tried to measure GD32 clock input, as below.
>
>
>
>
>
> Well, at least the GD32 seems like it is being clocked. Please see the
> signal below.
>
>
>
> Since there is no SPI or I2C activity at all, it seems like the GD32
> MCU simply isn't running any code.
>
> However, it is being clocked.
>
> And its Vdd is stable at 3V (I measured pin 48 with trigger on falling
> edge at level 2.7V on SINGLE SEQ mode, and there were no drops once
> the NanoVNA was turned on).
>
> So what could been happening?
>
> If the GD32 had died, it wouldn't have magically revived this week,
> only to die again.
>
> Maybe it's cold solder?
>
> Do you have any ideas of other test points I should measure?
>
> Best regards,
> Paulo Matias
>

Hi DK7OB,

Good idea! I have just checked pin 7 (below).

Measuring under oscilloscope, it is constantly high after the NanoVNA is powered on, as expected.

However, look how odd the PCB is:

Does somebody have the same version of the board to please confirm if there should be any component at the places pointed out by arrows? It looks like R327 and C319 are missing.

Since the MCU might not be reset for the adequate amount of time when it is powered on, it might be entering some bad state.

If NanoRFE or other colleague who owns the V2Plus4 board confirms the components should be there, I will go shop them tomorrow to try fix the board.

Best regards,
Paulo Matias

Hi Siegfried,

Yes, I've checked both. Messages are arriving with some delay, but I've checked the mechanical pressure hypothesis in a previous message. Also I've unplugged and replugged the panel several times.

Best regards,
Paulo Matias

I'm out of ideas now, Paulo.
But you appear very well equipped to diagnose the problem.

NanoVNA Support often monitor this forum. Perhaps they may be able to
provide further guidance?

73

Dave, G1OGY


On Sun, 6 Aug 2023 at 15:29, <syscoder@gmail.com> wrote:

> Hi Dave,
>
> I have measured the left button under the oscilloscope (please see the
> images below). It is pulled up to 3V by the MCU as expected and pretty
> stable. I have also checked that if I press the button, voltage goes down
> to zero as expected. So perhaps, a button issue is ruled out.
>
>
> (I know, the schematics are for 2.2, but this part of the circuit looks
> the same on V2Plus4).
>
>
>
>
>
> Best regards,
> Paulo Matias
>
>
>

looks like a stuck firmware .. not??

what if you press  button and boot?? does usb find it (in bootloader
mode)?? if not .. did you try with a different cable?? on a different
usb socket or even on a different pc??

you even can try to boot it in upload mode without a screen connected (i
had one unit that booted without screen but not with screen connected ..
also showed that white out)

dg9bfc sigi

Am 06.08.2023 um 16:43 schrieb syscoder@gmail.com:

> Hi Siegfried,
>
> Thank you for your hypothesis. I have just tested it. I have measured
> LCD−IRQ (at CONN303) under the oscilloscope and it's high. It only
> goes to low when I press the screen. Therefore, touch screen is not
> constantly pressed.
>
> Going further on possible test points, I measured (also at CONN303):
>
> T−CS (connected to GD32 PB7, xpt2046_cs): constantly low (even over
> reboots)
> LCD−DC (connected to GD32 PB6, ili9341_dc): constantly low (even over
> reboots)
> LCD−CS (connected to GD32 PA15, ili9341_cs): constantly high once the
> device is powered
>
> Looking at
> https://github.com/nanovna-v2/NanoVNA2-firmware/blob/master/board_v2_plus4/board.hpp#L61-L63
> and
> https://github.com/nanovna-v2/NanoVNA2-firmware/blob/master/board_v2_plus4/board.cpp#L206-L229,
> we can see all above are set as outputs in the first routine which
> runs once the firmware starts (assuming not much in this regard have
> been changed in the proprietary firmware).
>
> T−CS and LCD−CS are also set as high in the same routine.
>
> However, T−CS is measured as low. Let me stress out I set the
> oscilloscope to trigger on rising edge at level 1.5V and put it in
> SINGLE SEQ mode while the NanoVNA was being powered up. Another
> evidence firmware is not starting to run.
>
> Any ideas? Should I proceed to try heating the GD32 up? Or a cold
> solder could be elsewhere?
>
> Best regards,
> Paulo Matias
>

Hi Siegfried,

On Sun, Aug 6, 2023 at 10:00 PM, Siegfried Jackstien wrote:

>
>
>
> what if you press  button and boot?? does usb find it (in bootloader
> mode)?? if not .. did you try with a different cable?? on a different usb
> socket or even on a different pc??
>
>

When trying to enter bootloader by pressing the "left" button while turning the device on, I was getting the same enumeration errors. Yes, I tried with 5 different cables on 3 different computers - two Linux machines and one Windows 10. Just for sake of completeness, the message displayed on Windows was "The last USB device you connected to this computer malfunctioned, and Windows does not recognize it."

>
>
>
> you even can try to boot it in upload mode without a screen connected (i
> had one unit that booted without screen but not with screen connected ..
> also showed that white out)
>
>

Nice to know, I was not sure if it was supposed to work with the display module disconnected. Is it only for the bootloader (upload mode) or is it supposed to work for normal operation (with NanoVNA-QT) when the display module is disconnected?

By the way, now the device magically started to be able to enter the bootloader (upload mode), either with display module connected or disconnected. I swear I tried it several times over the past few days and it would only give enumeration errors, but now it was recognized:

[140931.740668] usb 2-2: new full-speed USB device number 34 using xhci_hcd
[140931.906509] usb 2-2: New USB device found, idVendor=04b4, idProduct=0008, bcdDevice= 0.01
[140931.906523] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[140931.906528] usb 2-2: Product: USB DFU
[140931.906531] usb 2-2: Manufacturer: USB DFU
[140931.906534] usb 2-2: SerialNumber: USB DFU
[140931.949612] cdc_acm 2-2:1.0: ttyACM0: USB ACM device

Now I've tried several times to flash both https://nanorfe.com/downloads/20220814/nanorfe-20220814-v2plus45.bin and https://nanorfe.com/downloads/20211227/nanovna-v2-20211227-v2plus4.bin. Neither worked. I get the following message on NanoVNA-QT:

Uploading firmware...

Done
95 KiB

If the firmware update is interrupted, you can re-enter DFU
mode by holding down the JOG LEFT button while power cycling
the device.

However, after that, the device remains with white screen. If I try to connect again to device on NanoVNA-QT without rebooting the device, NanoVNA-QT freezes. If I reboot the device after flashing, dmesg shows USB enumeration errors.

Still, now I can reboot holding the "left" button and it will enter the bootloader (upload mode) again.

I don't know if it's helpful, but I've attached to this message a capture of USB traffic during the flash procedure, made using usbmon/wireshark.

Best regards,
Paulo Matias

i use nano vna APP .. not qt

i use fw only from displord .. be it on the plus4 or on the saa2n
(v2clone with 4 inch and n sockets)

if you can get it into bl mode then its not dead but maybe you used the
wrong fw??

yes it runs also in pc mode without screen

that way i found out that screen makes noise on upper end cause it
rattles on the power rails (same as the power that is used to MEASURE)
so screen may produce a bit dirt (v2plus4 is quite clean but normal v2
can be improved a few db above 2 or 3 ghz)

greetz sigi dg9bfc

Am 07.08.2023 um 20:03 schrieb syscoder@gmail.com:

> Hi Siegfried,
>
> On Sun, Aug 6, 2023 at 10:00 PM, Siegfried Jackstien wrote:
>
> what if you press  button and boot?? does usb find it (in
> bootloader mode)?? if not .. did you try with a different cable??
> on a different usb socket or even on a different pc??
>
> When trying to enter bootloader by pressing the "left" button while
> turning the device on, I was getting the same enumeration errors. Yes,
> I tried with 5 different cables on 3 different computers - two Linux
> machines and one Windows 10. Just for sake of completeness, the
> message displayed on Windows was "The last USB device you connected to
> this computer malfunctioned, and Windows does not recognize it."
>
> you even can try to boot it in upload mode without a screen
> connected (i had one unit that booted without screen but not with
> screen connected .. also showed that white out)
>
> Nice to know, I was not sure if it was supposed to work with the
> display module disconnected. Is it only for the bootloader (upload
> mode) or is it supposed to work for normal operation (with NanoVNA-QT)
> when the display module is disconnected?
>
> By the way, now the device magically started to be able to enter the
> bootloader (upload mode), either with display module connected or
> disconnected. I swear I tried it several times over the past few days
> and it would only give enumeration errors, but now it was recognized:
>
> [140931.740668] usb 2-2: new full-speed USB device number 34 using
> xhci_hcd
> [140931.906509] usb 2-2: New USB device found, idVendor=04b4,
> idProduct=0008, bcdDevice= 0.01
> [140931.906523] usb 2-2: New USB device strings: Mfr=1, Product=2,
> SerialNumber=3
> [140931.906528] usb 2-2: Product: USB DFU
> [140931.906531] usb 2-2: Manufacturer: USB DFU
> [140931.906534] usb 2-2: SerialNumber: USB DFU
> [140931.949612] cdc_acm 2-2:1.0: ttyACM0: USB ACM device
>
> Now I've tried several times to flash both
> https://nanorfe.com/downloads/20220814/nanorfe-20220814-v2plus45.bin
> and
> https://nanorfe.com/downloads/20211227/nanovna-v2-20211227-v2plus4.bin.
> Neither worked. I get the following message on NanoVNA-QT:
>
> Uploading firmware...
>
> Done
> 95 KiB
>
> If the firmware update is interrupted, you can re-enter DFU
> mode by holding down the JOG LEFT button while power cycling
> the device.
>
> However, after that, the device remains with white screen. If I try to
> connect again to device on NanoVNA-QT without rebooting the device,
> NanoVNA-QT freezes. If I reboot the device after flashing, dmesg shows
> USB enumeration errors.
>
> Still, now I can reboot holding the "left" button and it will enter
> the bootloader (upload mode) again.
>
> I don't know if it's helpful, but I've attached to this message a
> capture of USB traffic during the flash procedure, made using
> usbmon/wireshark.
>
> Best regards,
> Paulo Matias
>

Hi Siegfried,

On Tue, Aug 8, 2023 at 11:05 PM, Siegfried Jackstien wrote:

>
>
>
> i use fw only from displord .. be it on the plus4 or on the saa2n (v2clone
> with 4 inch and n sockets)
>
>

Where can I download firmware from DiSlord for the plus4? This repo is the only one which seems to have prebuilt firmware: https://github.com/DiSlord/NanoVNA-D/releases/tag/v1.2.20 however it does not mention the plus4 anywhere.

This other repo mentions the plus4, but there are no prebuilt files. Should I compile the firmware myself? https://github.com/DiSlord/NanoVNA-V2-firmware

Also, would using non official firmware nullify warranty? I'm still waiting NanoRFE to answer on Aliexpress message center (or here via the group, if I understood well, the nanov2support account is operated by NanoRFE people?) whether they can give warranty service for this device. This is also why I still didn't try to mess with soldering yet.

>
>
>
> if you can get it into bl mode then its not dead but maybe you used the
> wrong fw??
>
>

The NanoRFE website ( https://nanorfe.com/nanovna-versions.html ) says these firmware I flashed August 7 are compatible both with V2 Plus4 and V2 Plus4 Pro.

Also please note the issue I'm encountering was certainly not caused by a firmware upgrade, since August 7 was the first time I tried to flash the firmware.

Also, today when trying to enter the upload mode I got enumeration errors again. I had to reboot the device (holding the "left" button) 6 or 7 times before it would be recognized correctly by the PC. After it was recognized for the first time, I rebooted it a few times for testing purposes and it would be recognized every time.

So almost certainly there is a hardware issue.

>
>
>
> yes it runs also in pc mode without screen
>
>

Nice to know. Since the issue arise, I did several tests trying to boot the board without the display, but every time I would get USB enumeration error.

Best regards,
Paulo Matias