NanoVNA-D
NanoVNA-D copied to clipboard
DiSlord
NanoVNA-H v3.3 and NanoVNA-H4 v4.3 and freeze on v1.1.00
Both systems freeze after long time running (possibly hours) powered via USB (power supply only, no data connection).
The screen freezes with a normal display (ie not mid scan), no response to touch, button or jog wheel. Recovers fully on power cycle (ie OFF/ON).
The -H hardware is years old, and never shown this on ttrftech firmware.
A possible memory leak?
Owen
Owen, Can you provide more info on this?- How long did it run before hanging?- How was the Display, Format, Scale, Stimulus, etc setup? If you are able to save a copy of your device instance using the Dump Firmware feature in Expert Settings and post it, it can be loaded on another device for comparison/verification of the issue you're seeing. I saw something similar when I compiled an earlier version of DiSlord's FW a few months ago, so there may still be something lurking deep down. Thanks,Larry
On Thursday, January 27, 2022, 05:33:42 p.m. EST, Owen Duffy ***@***.***> wrote:
Both systems freeze after long time running (possibly hours) powered via USB (power supply only, no data connection).
The screen freezes with a normal display (ie not mid scan), no response to touch, button or jog wheel. Recovers fully on power cycle (ie OFF/ON).
The -H hardware is years old, and never shown this on ttyrftech firmware.
A possible memory leak?
Owen
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: @.***>
Owen, Can you provide more info on this?- How long did it run before hanging?...
It is usually many hours. It failed this morning, about 10h after it was powered up.
No memory leakage in nano (not use dynamic memory allocation) This can be hardware due to overclock i2c bus
hi all, i use nanoVNA H4, so i was update fw to 1.1.0.0,. but when use marker in minimum, i cant get center frekwency like before,.. btw, how to center marker, im newbee and thanks
No memory leakage in nano (not use dynamic memory allocation) This can be hardware due to overclock i2c bus
There are 3k9 pullup resistors on the I2C bus, afaik, good for max 100-400kHz speed. For higher speeds use something like 1k-2k2 instead.
In LiteVNA use ~1.5M i2s bus, and all stable (but use MS5351 generator) and yes use 2k2 resistors. So possible this help.
PS try also last v1.2 i made small fixes (for H4), and possible solve issue? (as monomum drop one channel measure)
PS try also last v1.2 i made small fixes (for H4), and possible solve issue? (as monomum drop one channel measure)
@DiSlord: I've changed the TARGET to F303 in the Makefile (master branch) and made a build. Is that output the 1.2 binary or do I need to tweak some settings in the nanovna.h in order to get the 1.2?? No need to switch into H4 branch ?
OK, then you have to fix the "ui_mode_normal(void)" function in the H4 branch too.. Edit: I've build v1.2 for H4 from the source as-is (did the fix as it is in the master) and flashed into my H4. Looks nice!
There are 3k9 pullup resistors on the I2C bus, afaik, good for max 100-400kHz speed. For higher speeds use something like 1k-2k2 instead.
I replaced R7 and R8 on a -H4 r4.3 with 2k2, and the device still froze after about 12 hours.
PS try also last v1.2 i made small fixes (for H4), and possible solve issue? (as monomum drop one channel measure)
So, the H4 with 2k2 I2C pullups...
I downloaded v1.2.15 build from Ho-Ro's site, and installed it, did a basic OSLT cal, and just left it running (with external power), and it froze after about 20h.
Owen
My -H and -H4 build uses DiSlord's unmodified source code. I simply extract his version, create a new branch, build the bin and hex file with the version name, and push it into the new branch to make it accessible:
VERSION=$(grep "#define VERSION \"[0-9]*\.[0-9]*\.[0-9]*" main.c | cut -d\" -f2)
git checkout master
# delete "old" local and remote branch
git branch -D $BRANCH
git push origin -d $BRANCH
# create "new" local branch
git checkout -b $BRANCH
make clean; TARGET=F072 make -j \
&& ln build/ch.bin NanoVNA-H.bin \
&& ln NanoVNA-H.bin NanoVNA-H_${VERSION}.bin \
&& ln build/ch.hex NanoVNA-H.hex \
&& ln NanoVNA-H.hex NanoVNA-H_${VERSION}.hex \
&& hex2dfu -i NanoVNA-H.hex -o NanoVNA-H.dfu \
&& ln NanoVNA-H.dfu NanoVNA-H_${VERSION}.dfu
make clean; TARGET=F303 make -j \
&& ln build/ch.bin NanoVNA-H4.bin \
&& ln NanoVNA-H4.bin NanoVNA-H4_${VERSION}.bin \
&& ln build/ch.hex NanoVNA-H4.hex \
&& ln NanoVNA-H4.hex NanoVNA-H4_${VERSION}.hex \
&& hex2dfu -i NanoVNA-H4.hex -o NanoVNA-H4.dfu \
&& ln NanoVNA-H4.dfu NanoVNA-H4_${VERSION}.dfu
Do you encounter this freeze always after a similar time or also shortly after start. If it is a random issue, it should happen also sometimes much earlier. If it is a temperature thing, then 20 h are quite long. You could try it at lower temp, e.g. outside on the window sill (if you're located in the northern hemisphere). How do you detect the moment of freeze? Other idea: Do you have a logic analyser, e.g. a cheap 16 bit thingy? Then you could check the state at the moment of freeze - according to Murphy then the device will run forever :)
How do you detect the moment of freeze? Other idea: Do you have a logic analyser, e.g. a cheap 16 bit thingy? Then you could check the state at the moment of freeze - according to Murphy then the device will run forever :)
If you read back, I have the same issue with DiSlord firmware on a -H and a -H4, the -H is years old and never had freezes on other firmware.
The freeze is usually somewhere from 10-24h, sometimes within a few hours, almost never exceeding 24h. I just look at as I pass and note whether it is updating... nothing more scientific than that.
Thanks for the thoughts.
Owen
The screen freezes with a normal display (ie not mid scan), no response to touch, button or jog wheel. Recovers fully on power cycle (ie OFF/ON).
I did the owenduffy test with my -H v.3.4. My screen stops updating after a few hours, but unlike his observations, the screen responds to a touch - the menu opens and updating starts again. I will set up a test tomorrow to see if it is just the display refreshing or if the signal output also stops. UPDATE: no freeze so far, but I remember that with the last "unexpected stop" also the blue LED was off and started to blink with the 1st touch event on the screen.
After > 24h a freeze during sweep at CW 17.1 kHz (sweep range was 10 kHz - 20 kHz).
After connecting to the PC (it was on the charger) the device is found on USB:
[ +0,194061] usb 6-1: New USB device found, idVendor=0483, idProduct=5740, bcdDevice= 2.00
[ +0,000009] usb 6-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ +0,000006] usb 6-1: Product: NanoVNA-H
[ +0,000004] usb 6-1: Manufacturer: nanovna.com
[ +0,000004] usb 6-1: SerialNumber: 1.2.15_noSD
[ +0,003271] cdc_acm 6-1:1.0: ttyACM0: USB ACM device
It opens in picocom, answers to help, but freezes with resume:
ch>
ch> NanoVNA Shell
NanoVNA?
ch> help
Commands: scan scan_bin data frequencies freq sweep power bandwidth time saveconfig clearconfig dump touchcal touchtest pause resume cal save recall trace marker edelay s21offset capture refresh touch release vbat tcxo reset smooth config usart_cfg usart vbat_offset transform threshold help info version color
ch> resume
After unplugging it and plugging it back in, it is recognised again on the PC, /dev/ttyACM0 is there, but no serial communication is possible. Touch is also not active. Power cycle brings it to life again.
BTW: I learned during this test that the pause command (both from the touch menu and the serial port) stops immediately at a random frequency in the sweep range. Shouldn't it either stop at START or even better turn off port 1 altogether?
@DiSlord Is this comment in main.c still valid?
// Main thread stack size defined in makefile USE_PROCESS_STACKSIZE = 0x200
// Profile stack usage (enable threads command by def ENABLE_THREADS_COMMAND) show:
// Stack maximum usage = 472 bytes (need test more and run all commands), free stack = 40 bytes
//
Freeze still happens with -H FW 1.2.19 (c60f20a). Runnings over night, ok after 10 h, 20 min later the device has stopped in the mid of a scan without any reaction (no touch, no jog, no serial USB).
New information:
Simply having the USB connected (and the nanoVNA on...), without ever connecting to it with either NanoVNA-APP or Saver, is enough for the freeze (well, failure to connect) to occur, later.
I just got to my physical nanoVNA, and in this case the VNA screen is responsive, but windows won't connect to it.
Question: Does this have something to do with the Windows host? Does it occur when connected to Linux or OSX?
Paul -- AI7JR
Yes it does: I have been running NanoVNAs for days during the last couple of years, connected to a Raspberry Pi 4 running GNU/Linux (Buildroot build), and the freeze occurs after 15-24 hours. Just got to this thread after a freeze after 17.5 hours (saving the curve every 10 seconds).
