To Erik, Hugen, ttrf (de facto code "owners")
*The Command Stability Issue:*
Some people have reported some stability issues with the usb command
interface, including the screen going white.
I have also noticed this issue with my own python experiments, and have
been investigating it over the last few days. I've found an easy and
reliable way reproduce the issue: I use putty to repeatedly type the "freq"
command with different frequencies, and monitor the result on the tx port
with a frequency counter. Although the usb interface continues to work, the
frequency stops changing after 4-8 "freq" commands. The screen will also
randomly go white, but much less frequently.
Once the nanovna gets into this state it needs to be powered off and on
again to restore normal operation; the usb reset command isn't sufficient.
I've reproduced this issue with Hugen's Aug 2nd firmware, and with a build
today based on Erik's firmware (here:
).
*The Temporary Workaround:*
In investigating this issue I have found that the problem is somehow
related to the UI thread calling draw_all_cells() in parallel to the usb
command thread running. Stability is improved by restricting when this
function is called. See the code snippet (just 4 lines are moved)(
)
This is a temporary fix until we find what the underlying cause of this
interaction is.
As described below, Hugen's firmware also needs stack size changes to
improve stability.
*Stack Size Issues*
The symptoms we see are typically associated with a thread's stack
overflowing the allocated area and trampling on adjacent memory. Indeed the
command thread makes function calls at least 12 deep to process the "freq"
command, and together with the parameters passed and local variables in
each function, consumes a lot of stack!
However I've eliminated this as a cause (at least for Erik's version). I
did so by following the chibiOS guide re. stack sizes (here:
). The default
nanovna build already set sets the mentioned build variables
CH_DBG_ENABLE_STACK_CHECK and CH_DBG_FILL_THREADS. I implemented a simple
memory dump command to let me do this testing (code also in the gist linked
above).
My conclusion is that Erik's firmware version has just 4 bytes spare stack
space. This could easily be accidentally "blown" by a future simple
software change (adding a parameter or another local variable). I therefore
recommend increasing the usb thread's stack size by 64 bytes, (and reducing
the UI stack size by the same amount, since it's stack is larger than
needed and there's no other memory left). The two lines to change are also
in the gist above.
I also believe Hugen's version has the usb thread far too small - the
"freq" command will definitely overwrite the UI's stack and cause
instability - this needs fixing.
We already have a proliferation of firmware versions, so I won't add to the
problem by adding my own. Instead I suggest the existing owners investigate
and take these changes forward as they see fit.
Rgds,
Dave
