Waring: v2.0 is not reliable

One thing that I think makes the Complex page more likely to cause a reboot is that it also runs a 'live' calculation of actual inputs in order to draw the graphs (actually all the mixers do, but the complex page does more due to the bar graph).

This may result in the adc query being interrupted by the mixer which would also call the adc which could cause issues.

it won't explain the issue on the main page, but it is certainly worth investigating further

Well, I've spent a couple very frustrating hours with my Devo8, and cannot reproduce reboots on either the main page or the mixer page.
I've tried with an without telemetry, I've not seen reboots with either my Ladybird or MiniCP (nor DSM2 or Hubsan).

I can reproduce the reboot on the changing the transmit power. That one is due to sending SPI commands from the main loop and from the interrupt loop concurrently. I've released a fix for that one.

I'll keep trying, but if I can't find any way to trigger a reboot, all I can do is guess at what might fix it.

I did see a reboot while changing pages while binding (after shutting off the dialog). I'm not sure if that is related to the other issues or not.

Hexperience wrote: PB, just a shot in the dark, but I noticed that the config that caused the reboot was set for 12 channels and had a few virtual channels as well. Were you using a config like that in your tests? Again, just a lay-mans guess, but could it be that a more complex config with more channels is causing a slow down in some way? Enough to set off the watchdog?

Yep. In fact I was using that exact config. Of course, I couldn't actually fly my birds around with it, but it is fine for binding, testing the telemetry, pumping the throttle, and generally playing around.

well, if there is actually a conflict between the main loop and the interrupts, moving the watchdog will have the effect of causing the transmitter to hang.
Of course, I don't know what is actually going on. My next step is to add timing code to determine how long each of the interrupt handlers takes to execute. that will, at least, eliminate one of the possible causes.

I've added timing debug code to deviation, and here's an example of what I see:Average # msec of the past 100 loops for each of:
radio: time to run the radio callback routine
mix: time to run the mixer evaluation routine
med xx/yy:
xx = time to run the 'medium' priority section (button/touch) in the main loop
yy = time between calls to the 'medium' priority loop (should be '5')
low xx/yy:
xx = time to run the 'low' priority section (gui update) in the main loop
yy = time between calls to the 'low' priority loop (should be '100')
Same as for Avg, except it is the largest value seen since the last time status was printed

Here are some results
What I've found is that it takes < ~35msec to redraw the main screen on a Devo8 with the stock layout moving sticks around (such that most objects are being redrawn frequenty)
It takes ~500msec to redraw the screen when changing pages
It takes ~300msec to disable the binding dialog
At least in normal circumstances, the radio transmission and mixer evaluation are not a significant amount of time.
Telemetry has no measurable impact on timing.
Setting the protocol to 'None' does not change these numbers, which confirms that the radio interrupt is not generally a significant performance impact.

So...drawing the GUI is really slow. I'm not sure why, as last time I measured it, I think it was ~30msec. I need to further investigate this.

Also, we can see that a 1sec watchdog is generally sufficient. if we hit it, then something besides the GUI delayed execution by an additional 500msec beyond the typical situation.
In the end, we didn't find any smoking guns from the timing info, though spending some time looking at GUI efficiency is warranted.

As I have been unable to figure out the cause of the reboots, I have reverted back to calculating the mixer in the main loop.
This should be virtually the same as in 1.2. There is some noticeable lag in the controls, since it can take 30msec to refresh the main screen, and 500msec when switching pages) but hopefuly it will no longer crash.
I also increased the watchdog timeout and added a watchdog reset to the model-reading.

PhracturedBlue wrote: As I have been unable to figure out the cause of the reboots, I have reverted back to calculating the mixer in the main loop.
This should be virtually the same as in 1.2. There is some noticeable lag in the controls, since it can take 30msec to refresh the main screen, and 500msec when switching pages) but hopefuly it will no longer crash.
I also increased the watchdog timeout and added a watchdog reset to the model-reading.

Does it mean, that the servo delay/jittery may come back?
Or that has been solved already?

Vlad, could you recheck?

FDR wrote: Does it mean, that the servo delay/jittery may come back?

Yes, it has place. Slight delays (not smooth) have place at main page with digital channel value in a box, no delays at mixer page, very long delays at channel monitor page (protocol DSM2, JR RD921).

I wonder, Tx reboot in time mixer setup has place with already saved model files (with version 2.00) or it has place with old model files from version 1.1.2 ???

Next question, reboots in time of flight have place with already saved model files (with version 2.00) or it has place in time of first flight with old model files from version 1.1.2 (without any saving) ???

I have the answer, with saved model file, as before, I have unsystematic reboots (v2.00).

At least 2 people have seen it reboot while in flight (though there are many others who have not seen that behavior).

The current code should no longer behave that way, but at a cost of worse response time from the Tx. I hope I'll soon figure out the real root cause and find a proper fix.

I believe I have identified the causes of the random reboots.
The old code could rad the ADC from both interrupt context (for the stick inputs) and from the main-loop context (for the tx voltage). We use the same ADC converter to read both values. While it would be very rare, if the interrupt happened while reading the voltage, that would likely cause a lockup.

I have changed the code to use DMA for reading all ADC values so that there should no longer be any chance of contention for the ADC.

Additionally on the mixer page, there was the same potential because we were re-reading the ADC values to compute the graph. I've fixed that too.

Since I think I've fixed the bug, I've put the mixer calculation back in the interrupt, since it gives much better responsiveness.

The new code absolutely needs testing. Included are dfu files for each tx (no need for a new filesystem). I'd like feedback on whether it is possible to trigger a reboot with this firmware. But of course, be careful, since it is brand new

EDIT: removed files. Newer ones are here:
www.deviationtx.com/forum/3-feedback-que...liable?start=40#3786