Closed vlamgat007 closed 1 year ago
Tested Standard and DSHOT150 protocols. Using Spedix IS45 2-6S LiPo DShot BLHeli_S 45A ESC. INAV does not lose Radio comms if I test the motor using Outputs tab. Motor runs as expected.
Also tested without battery connected and the issue still occurs.
Red failsafe indicator does not light up when error happens. It does light up if I do not trigger the error and switch off my radio.
Even though I have no control, data still coming through from plane to INAV LUA screen on radio.
what crossfire FW version do you use? There are some older versions with odd behavior like this.
Nano Div. RX - v6.19 Micro TX - v6.19 Unify Pro32 HV - v1.15 Agent X - v4.2.0
hmmm 6.19 should be stable. did you do a factory reset of your crossfire receiver and module after the last update? If you update from 6.14 or earlier you have to do a factory reset. Maybe try that and then see if the issue still appears.
if yes, I suggest to reset the FC to defautls and just set up the basics and see if this solves the issue. Save a DIFF ALL before that.
I did do a factory reset of the TX but not sure about the RX. I will test this later today and post my results. Thanks!
Rx you should reset first over the crossfire settings LUA. because you will lose binding and doing it last will be more difficult
Thanks, will do.
Ok, I think I have narrowed down the issue. The RX and TX reset did not fix the issue. As suggested I then reset the defaults on the board and started from scratch. I set up only one mode for arming on Channel 5. Every time I made a config change and saved it then tested (are + disarm) and verified if I still had radio connection. I continued till I hit the "Continuously trim servos on Fixed Wing" setting. As soon as I saved this and went through the test cycle, it froze up, and when I removed the setting the issue disappeared. I tested this multiple times to confirm.
I have not completed the setup, adding the rest of the modes etc. I will wait to hear back before making more changes.
Thanks.
this is really strange. can you please post a DIFF of your current config right at this point where enabling or disabling this setting causes the lockup?
Might have something to do with it, gets called when autotrim saves eeprom on disarm ?
Possible. But why does this block his RC inputs without commanding a failsafe?
@vlamgat007 do you use a switch to arm and disarm or do you disarm with a stick command?
Anyway. I was hoping that @DzikuVx would remove the auto-save for the continous servo trim as well, when he removed it for the bootup gyro calibration. After a one time trim save with stick I see no point in saving it after every flight with minimal changes. But that's stuff for a different discussion.
It looks like it suspends the Rx signal for a fixed 1.5s period (SKIP_RC_ON_SUSPEND_PERIOD
in rx.c
) before resuming the Rx signal regardless of whether or not eeprom has been saved ... which doesn't make sense. I'm guessing this isn't long enough for 5.1 which takes longer to save to eeprom. Perhaps 1.5s is right on the limit for some boards and not others, a timing issue. Although it would make more sense not to have a fixed time period but simply reset the suspend time when eeprom write has finished.
Having said that surely if it's writing to eeprom it shouldn't be doing anything else should it, like try to process Rx signals ?
@stronnag ?
@vlamgat007 do you use a switch to arm and disarm or do you disarm with a stick command?
There is no stick command to disarm anymore. I think it was even gone in 3.0.
Diff all at point of failure: https://pastebin.com/8YEMD5Bg
Please note the Failsafe triggered but I have had multiple times when there was no failsafe but I had no control.
@vlamgat007 do you use a switch to arm and disarm or do you disarm with a stick command?
There is no stick command to disarm anymore. I think it was even gone in 3.0.
I use a switch on channel 5 to arm and disarm.
diff all with no failsafe: https://pastebin.com/EDA0WcY8
Failsafe is suspended during eeprom save so it doesn't trigger when the Rx is suspended. The fact that Failsafe behaves erratically during this problem might indicate there is an issue with Rx suspend during eeprom save. Be useful to know why the Rx is suspended during eeprom save, not immediately obvious.
Also wondering if this has anything to do with https://github.com/iNavFlight/inav/issues/7128. The only time I had a Config wipe was on a plane that was connected to Configurator and powered from the battery when it happened. The Rx only works on that plane when on battery power not USB.
I have tried with battery connected and without (usb only) and had the same result.
Seems the Rx suspend during eeprom write is to do with https://github.com/iNavFlight/inav/commit/3a13edfdad83fb3eaeada195654fbadbe5acb495.
@vlamgat007 Can you try the attached firmware. It's the current master with Rx suspend time increased to 3 seconds. You'll need to use the latest 6.0 Configurator which can be found at http://seyrsnys.myzen.co.uk/inav-configurator-next/.
@vlamgat007 If you want to stick with 5.1 you might also want to try my 5.1 build without auto ContinuousServoAutotrim saving.
Thank you @breadoven and @0crap! I like having ContinuousServoAutotrim so I will try v6.0.0 first. I am tied up with work so I will get to this later today. Thanks!
@vlamgat007 Try whatever you like, but please be assured that in my 5.1 build ContinuousServoAutotrim is fully functional. Only it will not auto save (which seems to be your issue) the new values after you land and disarm. You can still save the new values if you wish, by going into the OSD and choose save and reboot.
@0crap, thanks for the clarification!
Success! I loaded 6.0 and flashed with the 6.0.0 firmware provided by @breadoven. I updated using the last Diff All that I posted and then tested the arm and disarm.
There is a bit of a longer delay before you get control back after flipping the disarm switch but that seems like a minor issue.
I completed the rest of the setup and everything seems to be working as expected.
BIG THANKS to everyone for your support on this!!
Let me know if you have any further special instructions. I take it that I need to keep my Matek F405-WSE Controller on 5.1.0?
@vlamgat007 Just remember the 6.0 firmware is dev standard so could have issues, not that I've had any problems. Other FC boards are fine on 5.1.0 if they work OK.
So it appears the default Rx suspend time setting during eeprom write is probably causing problems but it's not clear why it only seems to happen with Auto Trim on disarm but not with other eeprom writes such as sensor detection and Accelerometer calibration on boot up. I assume nothing odd happened previously with 5.1.0 during accelerometer calibration on boot, completed as normal with the beeper confirmation at the end ?
@breadoven maybe because when disarming, the actual eeprom write is done first before the actual disarm happens. So all radio inputs are still expected to be valid during that time. All other eeprom saves happen only in already disarmed state.
I just came back from flying the plane after the changes.
Bad news is that it froze up when i disarmed after I landed. Good news is that this happened after it was safely on the ground.
@breadoven maybe because when disarming, the actual eeprom write is done first before the actual disarm happens. So all radio inputs are still expected to be valid during that time. All other eeprom saves happen only in already disarmed state.
It waits until the Arming flag is disarmed before saving. Maybe the problem is Stats also get saved at the same time the Arming flag changes state. 2 eeprom writes in succession. Maybe this needs changing so you only write once on disarm.
Ah, missed the comment that the problem is still there. Probably worth trying @0crap's 5.1 version with the ContinuousServoAutotrim eeprom auto save removed to see if that fixes things. Not that it would help explain what the problem is even if it does.
I have loaded the firmware from @0crap. It has not frozen up yet, unfortunately I ran out of time to do a test flight.
Flew and did not hang up on me. Used the OSD to save. Strange enough my other wing using the 405-wse controller did hang up after landing and disarming :-|. This has not happened before during setup or last flight, not sure what changed.
Would appear this eeprom write on disarm is somehow randomly causing problems.
@vlamgat007 Do you have stats
set to ON ? Could try turning it OFF to see if that makes a difference. Test on the H743 with current 5.1.0 release that hangs every time you disarm. Stats writes to eeprom on disarm at the same time as the Continuous Autotrim but they're written separately. Hard to see how that could be an issue but maybe the timing causes problems.
Also noticed normal servo Autotrim (not continuous) does a saveConfigAndNotify()
on disarm rather than just writeEEPROM()
used for the Continuous Autotrim. Surely the same eeprom save method should be used for both.
@breadoven I agree. I think anything that saves on disarm should call saveConfigAndNotify(). Maybe that could just set a flag to do the actual saving and notifying in the next loop, so save is only done once.
While things get changes, I guess it might be a good idea to finally also disable autosave for Continous Servo trim. There is no point in saving it every time with deviations of 10us between flights. With the longer and longer save times I also see that as a safety issue when the disarm takes 1.5s or even longer after the disarm switch is applied. This can make the difference between a flesh wound and losing a hand. Just keep it for the classic autotrim and stats as for stats there is no other way and Autotrim is intentionally used on a single flight.
Saving happens after disarming so it doesn't increase disarm time. You lose the RC link during saving but the motors should have stopped by then.
But the Motors are actually still running. At least on a wing. Not sure about copters as dshot wilkl reset if the signal interrupts briefly during safe.
Stats = OFF on both planes
But the Motors are actually still running. At least on a wing. Not sure about copters as dshot wilkl reset if the signal interrupts briefly during safe.
You're right. I have a delay on disarming for another reason and don't use the servo trim stuff so wouldn't have noticed any additional disarm delays caused by eeprom saves (although I do have Stats enabled).
Seems even though the motors are set to the disarmed state in the mixer code it isn't actually written to the motors until after servoAutoTrim is processed during which the eeprom write will occur: https://github.com/iNavFlight/inav/blob/c6706adc91a8f6ae0a37163188342240378b2d39/src/main/fc/fc_core.c#L927
This doesn't look like the best way of doing things. Certainly shouldn't have multiple eeprom writes on disarm and the order of events isn't ideal especially if it delays disarming.
Stats = OFF on both planes
So only 1 eeprom write causes this problem which simplifies things. Only question is why and also why aren't others having the same problem.
Makes you wonder what happens if you turn Stats ON ?
Makes you wonder what happens if you turn Stats ON ?
I will test.
@breadoven I've consolidated the save calls in to a single action. Being on the next loop, this should also allow other tasks to complete; such as disarming. Of course, that will depend on the scheduler too.
Makes you wonder what happens if you turn Stats ON ?
I will test.
@vlamgat007 Did you get a result from this test in the end ?
Did you get a result from this test in the end ?
@breadoven I am sorry I have not! I will see if I can bench test tonight and fly over the weekend.
Makes you wonder what happens if you turn Stats ON ?
@breadoven I set stats = ON and it is freezing up again. This is with the firmware provided by @0crap on the matek h743-wing v2 board.
Makes you wonder what happens if you turn Stats ON ?
@breadoven I set stats = ON and it is freezing up again. This is with the firmware provided by @0crap on the matek h743-wing v2 board.
OK, well that clarifies things. Just need to work out what's wrong with the eeprom save now.
You could try the firmware for PR https://github.com/iNavFlight/inav/pull/8439 to see it makes any difference. It's available from:
https://github.com/iNavFlight/inav/actions/runs/3169611952
Is this version OK to test with @MrD-RC ?
Have the same with H743 Wing V3 ... #8450
Makes you wonder what happens if you turn Stats ON ?
@breadoven I set stats = ON and it is freezing up again. This is with the firmware provided by @0crap on the matek h743-wing v2 board.
Weird stuff.
I bench tested with the stats = ON
setting on my build and no issues. (MATEKH743 V2)
That said, it's not using the diff all from vlamgat007, just my own fully configured diff all setup.
After a arm
and disarm
the FC stays responsive.
Because autolaunch for fixed wing is always on, the arm command gives the "raise throttle" indication in the OSD.
At that point I disarm and do this over and over, no issues. (Stats screen shows up on OSD.)
Makes you wonder what happens if you turn Stats ON ?
@breadoven I set stats = ON and it is freezing up again. This is with the firmware provided by @0crap on the matek h743-wing v2 board.
Weird stuff. I bench tested with the
stats = ON
setting on my build and no issues. (MATEKH743 V2) That said, it's not using the diff all from vlamgat007, just my own fully configured diff all setup. After aarm
anddisarm
the FC stays responsive. Because autolaunch for fixed wing is always on, the arm command gives the "raise throttle" indication in the OSD. At that point I disarm and do this over and over, no issues. (Stats screen shows up on OSD.)
@0crap Are you using the same receiver type, i.e. crossfire ?
Current Behavior
I am in the process of upgrading a Matek H743-WING V2 Flight Controller + XF Nano Diversity setup from INAV 3.0 to INAV 5.1 and am running into an issue. When I arm and disarm the system, I lose all radio control to the board (in the Receiver tab the bars stop moving). I need to reboot the board to gain control. It does not seem like any of the other switches cause the same behavior. Firmware for the XF components (RX + VTX) have also been updated.
(FYI....I have successfully completed a similar upgrade for a different plane with a similar setup using Matek F405-WSE Controller + XF Nano and did not experience the same problem)
Steps to Reproduce
Additional context: dump all
https://pastebin.com/uVBzcK75
version
INAV/MATEKH743 5.1.0 Aug 19 2022 / 12:34:02 (76f22b25)
GCC-10.2.1 20201103 (release)