ChibiOS not respecting BRD_SAFETYENABLE intermittently

[Pedals2Paddles]

Bug report

Issue details
Pre-arm and arming check of safety switch intermittently fails even with parameter BRD_SAFETYENABLE disabled on initial power up and never clears until reboot. This never happened in nuttx, and I've experienced this on multiple occasions in ChibiOS (master and 3.6-RCx). Rebooting clears the problem until it happens again, seemingly at random.

I can see that the switch handling is a little different in ChibiOS than Nuttx. Something seems to be sneaking by once in a while on initial power up. I don't have disarmed logging enabled, but I don't think there's anything in the DF log that would related to this?

@rmackay9 for FYI. I experience this in copter, but I don't think it's a copter issue since the copter code just gets its information from board libraries.

Version
Copter 3.6 and 3.7 master

Platform
[ ] All
[ ] AntennaTracker
[X] Copter
[ ] Plane
[ ] Rover
[ ] Submarine

Hardware type
Cube

[Pedals2Paddles]

Probably also related to this, where ChibiOS is not respecting BRD_SAFETYMASK: #9268

[Pedals2Paddles]

Tagging this safety, since if it can accidentally ignore to prevent arming, it can probably accidentally ignore and allow inadvertent arming too.

[MidwestAire]

I found last Saturday this issue will cause an in-flight disarm as well. The only way to completely disable what I now call the "Fully Automatic Random Crash Switch" is to physically disconnect it from the board. On Here GPS units pull pins 6 & 7 from the plug. On others don't plug in the switch.

The ChibiOS builds will still randomly complain about the "Hardware Safety Switch" on boot even with it disconnected and disabled. But if it is not connected I have had no further in-flight disarms.

[Pedals2Paddles]

@ChristopherOlson you sounds like you're describing a hardware defect with the button on your HERE. Vibration and wind causing inadvertent contact. I don't think that's related to a firmware issue being described here. Have others experienced this hardware problem you had or is just that one HERE?

[MidwestAire]

Nope, definitely a firmware issue. I was unsure of the hardware problem causing the flameout in flight. But the button still being enabled as shown on the bench when I have it disabled is random. If rebooted the controller it likely would not happen on the second boot. But when it happens it is the same as having BRD_SAFETYENABLE set to enabled instead of disabled, and it can disarm in flight.

So I determined the issue is exactly as you describe.

[Pedals2Paddles]

I agree there is an issue with the firmware in ChibiOS. If the parameter is disabled, it shouldn't ever do anything or be required. That's what the issue I opened is for.

But there is no firmware function that causes a physical button to push itself in flight. Something made that button make contact in flight. That's what I mean when I say hardware problem. Or is it loose? Or maybe the air pressure from the rotors blowing down on the button?

[MidwestAire]

Well, I had it disabled on that flight. BUT it was one of the times that I got the "hardware safety switch" messages when I fired up. Rather than rebooting I pressed the button. I had a subsequent flameout (was just starting to pull pitch when it flamed out). At first I thought I had over-fueled it and caused a tailpipe fire that caused combustor pressure to rise to compressor pressure and stalled the compressor. But then I saw the red LED flashing - it was disarmed.

That controller was the same one that came out of the gas helicopter and it had damage to the carrier board that may have caused the switch circuit to make contact and take the safety switch signal to ground.

BUT - the point is, I had the darn thing disabled in the settings. I don't use them at all on helicopters. And it was still enabled, despite my settings.

[Pedals2Paddles]

That heat could certainly have done it on the carrier end too. I don't have any actually operational aircraft besides the solo since the fire at my house. And the Solo's HERE does not have the safety switch connected so it's physically impossible to press on purpose or by accident.

Tridge's thought on the intermittent enable thing is a timing issue on boot. It is now on the (lengthy) to do list for ChibiOS. I think the safest thing to do is disconnect the safety switch from the carrier regardless if you're going to use ChibiOS.

[MidwestAire]

That's exactly what I have done is disconnect it. After further testing I found no way to positively disable it with the settings. Even with it disconnected I still get random "hardware safety switch" errors sometimes on boot. But with it disconnected if it self-enables there is no way for a hardware problem to cause it to disarm with it disconnected.

When it self-enables, it is the same as have having BRD_SAFETYENABLE set to 1, even if it's set to 0.

[Pedals2Paddles]

Well, unless that hardware problem was a hot engine warping the contacts in the carrier, in which case it could have happened with or without a physical switch installed. I'm putting my Solo back to nuttx for now. Between the safety switch and twitching gimbal outstanding issues, I can't use it in regular operation safely for now.

[MidwestAire]

Yes, I think it was the carrier. BUT - if it is disabled it should ignore it. It didn't. With the switch disconnected if I get the "hardware safety switch" error on boot, the only way to fix it is to reboot and see if goes away.

Realize I was testing on the bench to find the metrics that could cause an in-flight disarm after I found the problem. If the system boots without the hardware safety switch error I have not had it self-enable once the system is running. Only at boot.

[Pedals2Paddles]

I've not had it come up at any other time besides randomly on boot either. Tridge believes it is a timing issue where it's not catching the disable in time, so it shouldn't ever happen at any other time.

[MidwestAire]

That's what I think too. I have one sitting on the bench right now and I'm doing some more testing with a switch hooked up to make sure it doesn't do anything else that is weird or strange.

[MidwestAire]

@Pedals2Paddles Matt, there is still a logic problem in the code. With BRD_SAFETYENABLE = 0 if I set BRD_SAFETYOPTION to 3 the switch is still active every single time at boot. It can still disarm in flight if that switch signal is pulled to ground, no matter what causes it.

If BRD_SAFETYENABLE is set to 0 (disabled) that switch should be disabled. The BRD_SAFETYOPTION should apply if BRD_SAFETYENABLE = 1. Tested it with both NuttX on a Cube and with ChibiOS on a Pixhack V5 and got the same behavior.

So my opinion is the BRD_SAFETYOPTION logic is broken and it is over-riding the BRD_SAFETYENABLE setting.

Can add Copter 3.5.7 to the list too. It is also broken in 3.5.7 NuttX - tested with a Cube and Here GPS.

[Pedals2Paddles]

I agree. I think that's a separate issue from this one so it needs it's own issue opened.

[MidwestAire]

I'll open a separate issue for the code logic.

[rebenstein]

I have experienced the same issue. BRD_SAFETYENABLE = 0 and once in a while MP will come back with Hardware Safety Switch error in PreArm. I reboot inn MavProxy and it clears it up. Happens maybe once in 20 times. I have another issue with the PixHack V5 in that, the safety switch pin is sometimes low and therefore cannot detect the button press. That may be a HW problem as I have 2 other UARTs which are bad and the board is going back. My other PixHack v5 is checking out nice and clean

[Pedals2Paddles]

If anyone can save and post a tlog from this happening, that is needed to troubleshoot. Thx.

[tridge]

This PR attempts to fix the problem:
#9353