arm and disarm causes MATEKH743 to lose connection with radio in INAV 5.1.0

[vlamgat007]

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

1. Switch on Radio
2. Power up the plane (plug in battery) (the issue exists with and without battery connected)
3. Connect to board with PC via USB
4. Connect to board using INAV 5.1.0
5. Verify that Receiver is connected (all control surfaces moving and bars moving in Receiver tab)
6. Wait for the system to be ready to arm
7. When ready to arm, flip the arm switch
8. Disarm
9. At this point the board stops responding to the radio (bars not moving in the Receiver tab and control surfaces on the plane not moving)
10. Reboot the board to regain control

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)

• FC Board name and vendor: Matek H743-WING V2 Flight Controller
• INAV version string: 5.1.0

[0crap]

@0crap Are you using the same receiver type, i.e. crossfire ?

I use a ExpressLRS RX (EP1 on v3.0). Which does use the CRSF protocol between RX and FC.

[MrD-RC]

https://github.com/iNavFlight/inav/actions/runs/3169611952

Is this version OK to test with @MrD-RC ?

Yes, all good.

[EhAye]

i'm having a similar problem. H743-WING v2, and tried two different ELRS RX

i can trigger the failsafe by moving yaw to the left or right and holding it there. (0 throttle, pitch&roll middle). This seems to trigger the failsafe a lot more reliably than arm/disarm with a switch... which only causes a failsafe sometimes.

After a failsafe, i tried to reboot the RX and TX (leaving the FC running) by using the elrs lua script. They bind and TX gets full telemetry including GPS telemetry, but failsafe RX flag remains & channels remain unresponsive.

stats=on or off doesn't seem to make any difference, though my vtx isn't powered

[MrD-RC]

That sounds like an ELRS issue to me. It is the ELRS receiver that tells INAV it is in failsafe, not the other way around. INAV does not command failsafe, it only does what it is told.

[breadoven]

i can trigger the failsafe by moving yaw to the left or right and holding it there. (0 throttle, pitch&roll middle). This seems to trigger the failsafe a lot more reliably than arm/disarm with a switch... which only causes a failsafe sometimes.

INAV 5.1.0 ? And is this failsafe caused by the yaw stick movement when armed or disarmed or both ?

[EhAye]

INAV 5.1.0 ? And is this failsafe caused by the yaw stick movement when armed or disarmed or both ?

when i arm with a TX switch, the yaw movement does not cause failsafe. It only happens when ch5 switch is disarmed. yes inav 5.1.0

[b14ckyy]

The only stick command that has a centered pitch/roll and a full yaw right input is the Arming Safety bypass but that should not trigger anything else than that. isn't one of the yaw stick movements also used for HDZero or Runcam Cameras to enter the camera menu? Is this maybe a ELRS feature that is triggered and reporting a FS to prevent arming while in the menu?

[breadoven]

INAV 5.1.0 ? And is this failsafe caused by the yaw stick movement when armed or disarmed or both ?

when i arm with a TX switch, the yaw movement does not cause failsafe. It only happens when ch5 switch is disarmed. yes inav 5.1.0

I'm still not sure what you're saying here. It sounded like a failsafe can be triggered just by moving the yaw stick left or right without touching the arm switch. Are you in fact saying that the failsafe is only triggered when using the arming switch to disarm but the failsafe is more likely to occur with the yaw stick held hi or low when disarming ?

[EhAye]

isn't one of the yaw stick movements also used for HDZero or Runcam Cameras to enter the camera menu? Is this maybe a ELRS feature that is triggered and reporting a FS to prevent arming while in the menu?

It also failsafes on Throttle up, Yaw left, Pitch up Roll Right (both up and to the far corners) I can't see any commands listed in the documents associated with this position, but it causes a failsafe as well.

The Calibrate Compass stick command causes a failsafe as well (Throttle up, Yaw Right, Pitch down).... most positions don't cause it. But these do.

[EhAye]

I'm still not sure what you're saying here.

sorry. I get failsafes when DISARMING* with channel5 switch sometimes.

But while disarmed, if i move the yaw stick to the left and hold it there for about 2 seconds, i get a failsafe every time. There's a few other stick commands that will cause failsafe as well, like the Calibrate Compass command

[breadoven]

That sounds like an ELRS issue to me. It is the ELRS receiver that tells INAV it is in failsafe, not the other way around. INAV does not command failsafe, it only does what it is told.

If it's related to https://github.com/iNavFlight/inav/commit/3a13edfdad83fb3eaeada195654fbadbe5acb495 then it could be an INAV problem although it's odd it only seems to affect these H743 boards.

[EhAye]

That sounds like an ELRS issue to me. It is the ELRS receiver that tells INAV it is in failsafe, not the other way around. INAV does not command failsafe, it only does what it is told.

If it's related to 3a13edf then it could be an INAV problem although it's odd it only seems to affect these H743 boards.

While its in the RX failsafe state, i put both the RX and TX into wifi mode and hit the "Save & Reboot" button, to reboot them while keeping the FC powered

They re-establish link and resume advanced telemetry normally. But the FC still reports RX failsafe and shows no channel movements on the flaps or receiver tab

Could inav just be getting 'stuck' in this state, and refusing to reset the flag?

[breadoven]

I'm still not sure what you're saying here.

sorry. I get failsafes when DISARMING* with channel5 switch sometimes.

But while disarmed, if i move the yaw stick to the left and hold it there for about 2 seconds, i get a failsafe every time. There's a few other stick commands that will cause failsafe as well, like the Calibrate Compass command

I assume it doesn't failsafe when moving the yaw stick if it's never been armed ?

[EhAye]

I assume it doesn't failsafe when moving the yaw stick if it's never been armed ?

freshly rebooting everything, i can simply move the yaw to the left, hold for 2 seconds, and it failsafes. Not touching anything else

[breadoven]

I assume it doesn't failsafe when moving the yaw stick if it's never been armed ?

freshly rebooting everything, i can simply move the yaw to the left, hold for 2 seconds, and it failsafes. Not touching anything else

OK, well that changes things if it does it without even disarming.

@vlamgat007 do you have the same thing happening just using the stick movements without ever arming ?

[EhAye]

I don't know if it means anything, but the "Serial Link Status" indicator flashes Grey a couple times right before the failsafe. Serial Link Status goes back to Blue once the failsafe has activated

[vlamgat007]

@vlamgat007 do you have the same thing happening just using the stick movements without ever arming ?

@breadoven and @EhAye Not something that I have noticed but it could just be because I do not use that stick command. I will need to test that specifically. I will get back to you on this.

Does it make a difference if the fc is usb or battery powered?

[EhAye]

Does it make a difference if the fc is usb or battery powered?

doesn't make a difference for me. Under battery power, no USB it still happens. It is sorta random'ish. Sometimes it failsafes immediately without touching anything.

BUT it doesn't seem to happen while armed. (going to test this more tomorrow)

DISARMED: In edgetx telemetry tab i noticed the inav telemetry sometimes halts briefly. This pause happens at the same time the stick/channel inputs become jumpy (feels exactly like a sudden & extreme framerate drop in a videogame). This pause happens every 1 - 5 seconds. Eventually one of these 'pauses' turns into a failsafe and the servos halt.

but the RX's telemetry doesn't miss a beat. It continues uninterrupted even when inav telemetry pauses briefly.

its also not just the 'stick commands' that can cause the failsafe. I was just moving the pitch/roll stick in a circle about half deflection to listen to the servos pausing. It failsafes quite quickly, after maybe 10 or so rotations.

ARMED: i'm currently getting no pauses, flight counter just called 11 minutes, no drops in telemetry, no servo pauses, no failsafes, no problems (so far)

After 11 minutes i disarmed. Everything seemed "fixed" at first, but then the channel/servo pausing came back after about 15 seconds, and already a failsafe from rotating pitch/roll at 1/3rd deflection after about 25 seconds.

I've got to leave for the day but i'll be leaving this armed and connected for a couple hours tomorrow to see if i can trigger the failsafe problems while armed

[EhAye]

i had left this unplugged and turned off for about an hour. I was wondering why the problem got progressively worse over time, so i turned it back on and tried it. I'm having a hard time making it failsafe again.

could this be a hardware problem? like bad crystal oscillator issue on the matek RX? could it be a bad oscillator that's heating up and changing frequency? (but this doesnt seem to happen while armed??)

its even surviving the yaw-left stick command that kills it 90% of the time. Just a minor hickup in servo movement when i do it

Edit: After about 5 minutes on, the servo/channel pauses are happening again, and im sure they'll turn into failsafes like before. I gotta go for the day

edit: yep failsafed

[EhAye]

I've had this armed on Battery (no USB) for over 2 hours and no problems with anything at all. No hickups on the flaps, no telemetry issues, no problems.

I tried simulating a failsafe by turning off my radio. the FC went into failsafe mode and spun up the motor. When link re-established, i was able to regain control and everything is still working fine.

I'm worried i'll get stuck in this "bugged failsafe" during a real flight.. But i can't seem to trigger the failsafe while its armed on battery. I guess that might rule out hardware problems?

[jayss66]

I am having this exact same problem. Crossfire receiver, Matex H743 wing V1, running INAV 6.0. I was just about to go to the flying field, I thought I had this problem solved last night as it didn't do it then when the battery was plugged in. I was double checking just now before I loaded it into the truck, and it did it again on disarm with only the battery plugged in. I will disable continuous trim servos for now. Thanks.

[MartinHugh]

I experienced a failsafe on two occasions yesterday as soon as I disarmed.

H743 + iNav5.1 + ELRS 3.0 (EP1) Continuously trim servos : Disabled. stats = OFF

[b14ckyy]

@MartinHugh do you by chance have Autolevel on together with ANGLE mode? Maybe post a DIFF please

[MartinHugh]

@MartinHugh do you by chance have Autolevel on together with ANGLE mode? Maybe post a DIFF please

Diff at : https://pastebin.com/Nn5Sx2CL AutoLevel and ANGLE are ganged together.

[b14ckyy]

I think Autolevel also autosaves. And also this is a tuning mode and should not be used constantly. maybe one of the devs can check if it autosaves, i am not 100% sure.

[MartinHugh]

I think Autolevel also autosaves. And also this is a tuning mode and should not be used constantly. maybe one of the devs can check if it autosaves, i am not 100% sure.

In case this is relevant : I am not convinced I switched into Angle/autolevel on both flights (only one). And when I did, it was only for 10s early on in the flight. Prior to disarming I was in Manual mode or Acro in both cases. I did not trigger a save from the sticks or OSD either at any time.

I was under the impression that autosave for autolevel was disabled in 5.1.0. Comments please on that anyone?

[breadoven]

Doesn't auto save from what I can see and also the Wiki states Autolevel needs to be manually saved.

But based on what @EhAye found this doesn't seem to be related to disarming anyway. Instead it appears to be related to just being in the disarmed state. It could happen immediately on disarming or perhaps by just by moving the sticks to the extremes when disarmed. Eeprom saves perhaps just increase the likelihood of it happening on disarm.

[vitaly-rudenya]

Same problem for me. For my case I've found that it's stops working in case saving !! flight modes !! After that reciever tab shows static values. Rebooting only FC (reciever keeps powered) solve the problem in a time Sime time it happend when just moving stics on my radio H743 V3 (INAV 5.1) + ELRS-R24-D (ELRS 2.0 and 2.51) tried on clean setup with UART6 and UART2

With INAV 5.0 permanently catching FailSafe

[breadoven]

For my case I've found that it's stops working in case saving !! flight modes !!

You mean changing and saving flight mode settings in Configurator causes the FC to lose the receiver signal ?. Does this also cause a failsafe ?

What causes the failsafe on INAV 5.0 exactly, it's always in Failsafe or only after doing certain things ?

I had a look at this trying to see why it only appears to happen when disarmed and couldn't find anything obvious. There doesn't seem to be anything that changes when disarmed that would affect the receiver signal or CRSF processing. So a bit baffling really as to why this is happening.

Would be useful to know if it also affects receiver protocols other than Crossfire.

[MartinHugh]

OK, so I am not sure exactly what parameters we should be looking at - we may be describing different fault causes in this thread, so all I can do is report what I have seen.

As I mentioned above, I have reported multiple cases of failsafe immediately following disarm. This is not reliably repeatable. But it happened twice in the same flying session.

However following on from the recent posts by @vitaly-rudenya and @breadoven above. I happened to be reconfiguring my modes settings in configurator tonight. No battery fitted, FC just connected to USB, and transmitter on and connected to the RX, to test the positions of the mode selection sliders on the inav screen.

If, after making some small changes to the sliders I press "Save" on that tab in the configurator and then immediately move switches on the transmitter (e.g. in my case I was setting flight modes on SA/SB), the the modes animation freezes (sliders do not move) Also the receiver tab in configurator in static/frozen too. Nothing responds to the transmitter switches or gimbals without recycling the power to TX and FC. This seems to be repeatable.

Also of interest, when the fault is present :

• The GPS tab in configurator is still showing updates, which probably indicates that the FC MCU is still scheduling normally
• Telemetry is still being sent back from the RX to the TX (i.e. values are changing)
• The RX LED is indicating that it is bound to the TX

I am running MATEKH743 iNav 5.1.0 ELRS 3.0

[EhAye]

@MartinHugh I had similar issues when configuring my modes, saving, and switching to the receiver tab to check stick inputs. Sometimes it would failsafe while flipping between the tabs. Im not sure if it was the tab switch, or saving the mode page that triggered it... sometimes it happens shortly after switching to the reciever tab...

It also doesn't happen 100% of the time. Sometimes i can save and switch tabs just fine. But it will quickly failsafe within a minute or two, and its USUALLY triggered by me doing something (switching tabs, moving sticks, saving settings etc). Although occasionally it will failsafe automatically after bootup... But it ONLY happens while DISARMED. When its armed, i haven't noticed any bugged failsafe issues at all.

@vitaly-rudenya same with me. If i reboot the RX, the failsafe persists. But if i reboot the FC while keeping the RX on, the failsafe is cleared. The whole time i am receiving telemetry from both ELRS and iNAV.

Feels like the FC is getting bugged in a fake failsafe state... but only for this one processor?

[MartinHugh]

@MartinHugh I had similar issues when configuring my modes, saving, and switching to the receiver tab to check stick inputs. Sometimes it would failsafe while flipping between the tabs. Im not sure if it was the tab switch, or saving the mode page that triggered it... sometimes it happens shortly after switching to the reciever tab...

@EhAye Interesting, In my case it I was not switching tabs until after the freeze had occurred, so for me at least the tab switching was not the trigger.

[vitaly-rudenya]

e

So there is no fail save due-to values update stop.

But permantly catcing serial loss and FS on INAV configurator when ELRS is connecting. With Arducopter with same hardware all works fine

And I don't have those issues on this FC with Fli14 Plus 14CH Mini (FlySky, SBUS) on same UART

[breadoven]

• Telemetry is still being sent back from the RX to the TX (i.e. values are changing)

Does this include FC related telemetry or just the native Rx telemetry (signal info LQ, RSSI etc) ?

From what @vitaly-rudenya reports it does seem to be CRSF related. Only reason CRSF would cause a failsafe is if there are no packets being received by the FC or the packets are bad (CRSF doesn't use a failsafe flag from what I can glean, just uses no pulses on failsafe).

[MartinHugh]

• Telemetry is still being sent back from the RX to the TX (i.e. values are changing)

Does this include FC related telemetry or just the native Rx telemetry (signal info LQ, RSSI etc) ?

From what @vitaly-rudenya reports it does seem to be CRSF related. Only reason CRSF would cause a failsafe is if there are no packets being received by the FC or the packets are bad (CRSF doesn't use a failsafe flag from what I can glean, just uses no pulses on failsafe).

Great question. I have just checked. The fault induced first time. Very reproducible.

At the point that the configurator GUI first freezes, all the telemetry displayed in the TX freezes and is displayed red - I would infer this as a failsafe condition, though I have not warning or other indication of this from the configurator.

Then about 1s after, the telemetry all springs back into life. RX telemetry + FC telemetry. But the configurator remains frozen and moving TX switches has no effect on it

[MartinHugh]

From what @vitaly-rudenya reports it does seem to be CRSF related. Only reason CRSF would cause a failsafe is if there are no packets being received by the FC or the packets are bad (CRSF doesn't use a failsafe flag from what I can glean, just uses no pulses on failsafe).

@breadoven, is your hypothesis then that the saving of the configuration causes a delay in the RX UART being serviced, such that the FC decides it has failsafed ? Is the ISR enabled during saving?

That is one thing, but the TX-RX link does reestablish, so why does the configurator not unfreeze ?

I am clutching at straws here :-)

Edit:

I have just installed a serial port monitor on the comport and data is being sent in both directions, despite the UI showing as frozen in places. And indeed, other tabs (OSD, Advanced Tuning) are loading the parameters from the FC normally

[breadoven]

What happens if Telemetery is disabled ? Also does setting failsafe_delay to the maximum (20s) make any difference ?

[MartinHugh]

What happens if Telemetery is disabled ? Also does setting failsafe_delay to the maximum (20s) make any difference ?

Telemetry disabled [in the LUA], makes no difference. Possible to cause lockup in configurator almost instantly

failsafe delay changed from 5ds to 200ds.
The first immediate freeze seemed to recover, but the one which followed it a second or so later did not.

[EhAye]

The first immediate freeze seemed to recover, but the one which followed it a second or so later did not.

I think this is the same freeze i get, when i'm rotating my pitch/roll stick at half deflection around and around smoothly to listen/watch the flaps, and i'll get a momentary pause/hickup in the servo response, which recovers after a second. If i watch on the receiver tab, the channel animations pause along with the flaps.

It will do this 1, 2, maybe 3 times. Sometimes it recovers, but a failsafe will eventually happen during one of these pauses.

I don't think its my stick movement that's causing it. I think there's just a periodic hiccup in the flight controller, and sometimes (usually) it causes a failsafe. I'm not sure what starts the hickups. It seems like doing anything can start them up.

Once that failsafe happens, the ELRS + FC telemetry continue to transmit for a while. I've noticed the FC telemetry drops out after 5 or 10 or 20 minutes... there's no set time... ELRS telemetry never stops.

during the pauses, i noticed "MSP round trip" and "HW round trip" spikes up high, while CPU load is unchanged https://i.imgur.com/zlcBlD7.png After the failsafe happens, the roundtrip times return to normal.

[EhAye]

This is really weird.

In the ELRS LUA script i DISABLED telemetry. In INAV Configuration tab, i DISABLED Telemetry.

I'm able to rotate my pitch/roll stick and everything seems fine. I move Yaw Left and hold it there for 2 seconds, no problem. (a few days ago, Yaw Left would reliably trigger a failsafe) I move Yaw Right and hold it there for 2 seconds, no problem.

I leave ELRS LUA telemetry DISABLED I ENABLE inav telemetry in the configuration tab:

I'm able to rotate pitch/roll stick and everything seems fine. I move Yaw Left and hold it there for 2 seconds, no problem. I move Yaw Right and hold it there for 2 seconds, Failsafe. Repeatable. (throttle position doesn't matter. I tried Throttle Up, Middle, Down, 1/4th. As long as Yaw-Right is held for a second, it failsafes)

Turning on and off inav telemetry, i am able to turn this Yaw-Right failsafe trigger on and off. I powered off all my hardware, let it rest for 5 minutes, then tried again. Same result. I can reliably turn the Yaw-Right failsafe off by turning inav telemetry off. Turning inav telemetry back on will enable the Yaw-Right failsafe.

EVEN STRANGER: Currently my Yaw is resting at 1498 on the receiver tab. If i very carefully nudge Yaw right to 1501 it will failsafe. I believe some other failsafes I've experienced is due to stick jitter nudging it over.

I changed EdgeTX's PPM Center for the Yaw channel to 1505. iNav's Reciever tab shows it at 1503 and it failsafed.

I kept EdgeTX PPM Center at 1505, and rebooted the Flight Controller. It appears to be stable., even though Yaw is resting at 1503 currently. I can now move Yaw around on the Right side no problem!

I move Yaw Right and hold it there for 2 seconds, no problem! I move Yaw Left and hold it there for 2 seconds, FAILSAFE! (Yaw at 1478 on receiver tab)

To to be clear:

• If my FC boots up with Yaw 1505, i can move Yaw around to the right without problem, but moving to the left will failsafe.
• If my FC boots up with Yaw at 1498, i can move Yaw around on the Left without problem, but moving it to the right will failsafe.

Disabling iNAV telemetry seems to solve MOST of this problem. With iNAV telemetry DISABLED, i am able to move each individual stick around to its extremes, holding it wherever i like, no problem.

HOWEVER, These other stick-combo positions will still cause problems, Even with inav telemetry Disabled OR enabled: Throttle down, Yaw left, Pitch down Roll right = the usual failsafe

Throttle Up, Pitch Down = MAJOR LOCKUP. This stick position failed differently. The failsafe parachute does not turn red, instead "Serial Link Status" repeatedly blinks, indefinitely. Different configurator tabs load extremely slowly if at all. Disconnected the configurator and tried to reconnect, it can't reconnect First reboot did not seem to fix it. Second reboot i was able to connect but the configuration was wiped out.

Upon restoring my diff, i am able to reproduce all of the above problems in this post...

I was also able to reproduce the major lockup... this time it took a few extra reboots before it came back to life.

I've just re-flashed (5.1 still) with full chip erase option. Restored diff. All of the above problems in this post are still repeatable.

Enabling ELRS LUA script's telemetry does not make a difference. (I've tried 1:8 and 1:32 ratios. 100hz full, 12ch mixed mode)

I just tried changing to ELRS 8ch switch mode. Same problems as above. inav telemetry switch still enables/disables the weird Yaw failsafe, and it still depends what 'side' of 1500 the yaw is on when it boots up.

I disabled everyting under "other features" except "stop motors on low throttle" and "enable motor and servo output", nothing seems different. The above problems are all still reproducible.

Changing failsafe_delay to 100 doesn't solve the problem, but the failsafe parachute icon takes a lot longer to turn red with failsafe_delay = 100

[breadoven]

@EhAye is this still only happening when Disarmed but never when Armed ?

[EhAye]

@breadoven yep, i've just armed it and tried. There is no hickups or failsafes when it is armed. upon disarm there was no failsafe. after i disarmed, i moved yaw left, and it failsafed. (my yaw is still around 1503 resting/at bootup)

While disarmed, powered via USB, the yaw-left thing causes failsafe about 95-99% of the time. While disarmed powered via BATTERY only (no USB), the yaw-left thing causes a pause/freezing of the channels (visible on the flaps) about 75% of the time. and results in a failsafe about 25% of the time. If i continue holding the yaw to the left, it will failsafe within 5 seconds every time... as if the pauses accumulate or become too long

While armed, USB or Battery powered, yaw doesn't cause any problems, no failsafes, no pausing/freezing. It seems to function fine.

i wonder if people's upon-disarm failsafes are caused by the 1500 yaw thing? if they hold their stick to the left or right when they disarm, i'd bet only one direction will cause failsafe upon disarm.

@breadoven I also just discovered the "tasks" command and noticed something interesting about the "telemetry" row. Before failsafe, i enter CLI and type "tasks", this is an example of the telemetry result:

14 - TELEMETRY 499 8 1 0.8% 0.5% 11

After a failsafe, i enter CLI and type "tasks", and this is what the Telemetry row looks like:

14 - TELEMETRY 497 36416 1 1810.3% 0.5% 123

The "maxload" column shows low numbers while not failsafed, but after failsafe its at "1810.3%"

@vlamgat007 could you try? just hold yaw left while you disarm a few times. And then try yaw right and disarm a few times? If you do it on USB you should get pretty repeatable failsafes. If you do it on battery, the failsafe is less repeatable.

On battery, I tried holding yaw to the side while disarming and had no problems the first 3 disarms (no pausing, no failsafes), but the 4th disarm i got a failsafe. Its less repeatable on battery.

[breadoven]

@EhAye can you provide a DIFF of your settings, not sure you did it before above.

[EhAye]

can you provide a DIFF of your settings

https://pastebin.com/t1HZKSMs is what i'm currently using

I also edited my previous post to add some information about the "tasks" command and the "TELEMETRY" row.

https://pastebin.com/B4K1Lih7 Here is 3 "tasks" results in this pastebin. 1st result is no failsafe, freshly booted, direct to CLI and typed "tasks" 2nd result is no failsafe, fiddled with the pitch/roll stick and armed/disarmed, then went to CLI and typed "tasks" 3rd result is after failsafe... i freshly booted, triggered failsafe by moving yaw left, then went to CLI and typed "tasks"

[breadoven]

@EhAye Looking at the stick movements you mention some of them are stick commands so intended to do something although they shouldn't cause lockups: https://github.com/iNavFlight/inav/blob/master/docs/Controls.md.

The Telemetry task info suggests the Telemetry is hanging for some reason and blocking the receiver signal possibly ?. 36,555 microseconds is way too long to process the task. Needs someone who better understands how CRSF works to really understand what is going on. You'd think the fact it only happens when disarmed would help narrow down the cause but it's not obvious what difference that makes.

[EhAye]

@breadoven whats even stranger is it seems to only effect some boards? Is EVERYONE with a "h743 wing v2" having this issue? or only some of us? I know lots of people are claiming to use H743 successfully... maybe they're using the -slim versions? I haven't seen anyone complain about the h743-slim yet, only the -wing variants.

Because of the hardware difference in success rate, it makes me wonder if there's not some deeper hardware bugs. But then people don't seem to have a problem with ArudPilot on the h743-wing-v2

What differences in software/hardware is there between the -wing and -slim? maybe there's just some bad crystal oscillators or pullup resistors on the -wing variants?

I wish i had continued programming when i was younger. I wasn't too bad at it. Although now 20 years later i'd be hard pressed to write a lua script

[MartinHugh]

Because of the hardware difference in success rate, it makes me wonder if there's not some deeper hardware bugs. But then people don't seem to have a problem with ArudPilot on the h743-wing-v2

@breadoven, just for the record, my problems are with the H743-wing-V3 not V2

[MrD-RC]

The H743-SLIM and H743-WING use the same target. In fact, all the Matek H743 flight controllers use the same firmware target. MATEKH743

[EhAye]

I tried unplugging the USB/beeper daughterboard and it made no difference.

I did notice the blue LED stops blinking while the channel/flap freezing is happening. The blue LED will stay off, or stay on (whichever it happened to be) for the duration of the freeze, and resume blinking after the freeze. After failsafe happens, it continues blinking normally. (normally there is a solid red LED and a blinking blue LED while disarmed)

Do we know of anyone who has a wing-v2 or wing-v3 without these problems?

If i flash Ardupilot with the stm flasher, is it possible to come back to inav after testing? I'm curious if i continue having problems with ardupilot. I know people who use wing-v2 and wing-v3 with ardupilot and they don't have problems. So if i continue having problems there it would suggest something wrong with my hardware. If the problem goes away, then i know its fixable ;D

[EhAye]

R:I:I:P

Progress (ish!)

I noticed this post over here https://github.com/ExpressLRS/ExpressLRS/issues/1818 It sounded awfully familiar. He doesn't mention his Flight Controller name. But he did mention the problem goes away after disabling ELRS VTX Administrator.

I tried disabling the VTX Administrator and poof. No more failsafes. I can move my yaw stick past 1500 while disarmed. No hickups, no pausing, no failsafes. I re-enable the VTX Administrator (R:I:I:P) and i get the yaw failsafes again.

So i currently have VTX Administrator Disabled, and i can re-enable inav telemetry, and all the problems appear to have vanished.