Bad ignition module /noisy RPM input can crash AP by generating too many interrupts

[AndKe]

Issue details

At least using PCI 1.3 ICE ignition module , this issue is 100% reproducible.
http://www.falkon.cz/op.htm

RPM_TYPE=2
RPM_PIN=54
When this ignition module is unpowered, / looses power, it will try to come to life using the weak pullup power from the Cube.
Feeding this module weak power from a IO pin, it will try to come to life, and pull down the weak pullup, effectively generating a 1Mhz signal (for this to work, the ignition module must not have external power, just GND and RPM signal connected.)
In real life, this happens if the ignition module die, or it's power supply fail.

This happens because the ArduPilot spends way too much time in the interrupt handling routine.

Reproducing on bench, no ignition module needed:
Configure as mentioned above.
From a signal generator;
1: apply 12kHz signal, observe that the CPU load barely increases
2: apply 35kHz signal, observe that the CPU load reach 96%
3: apply 100kHz signal, observe that autopilot becomes unresponsive/crashes repetitively

Summary:
a ground loop, disconnected long wire in a noisy environment or defective RPM sensor or ignition module , can produce more interrupts that ArduPilot can handle, resulting in repetitive reboots and sluggish behavior in between those reboots.

Solution would be to temporarily disable IRQ if incoming signal is too fast.

Version
AP 4.0.6

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

Airframe type
5.5m Plane

Hardware type
Cube2

Logs
(none attached)

[tridge]

I've reproduced the problem by connecting a 921600 baud uart to the RPM input pin

[tridge]

@AndKe can you please test the fix in #15388

[AndKe]

@tridge will check soon, please notify me when what @peterbarker pointed out is fixed.

[tridge]

@AndKe it's fixed, ready for your testing

[AndKe]

@tridge - I tried to ask you on gitter;

git pull upstream master
git submodule update
git fetch --all --tags
git checkout tags/ArduPlane-4.0.6 -b plane4.0.6-irq
git remote add tridge https://github.com/tridge/ardupilot.git
git fetch tridge 
git cherry-pick f131f94c078f00cccc56afcc277376ed86b7aed6
fatal: bad object f131f94c078f00cccc56afcc277376ed86b7aed6

• is it something I am missing?

[tridge]

@AndKe use gitk to cherry pick, and click the patch. You want this for 4.0.6 I presume?
I've now updated the plane4.0 branch to include this fix btw, in preparation for a new release once you've tested
https://github.com/ArduPilot/ardupilot/commits/plane4.0
I'll close this issue now. Please report your test results on the PR #15388

[stephendade]

For Dev Call: Discussion as to adding this as our first User Alert.

[AndKe]

@tridge

The patch works as intended, somewhere before 600kRPM pulses (RPM_SCALING = 1) there is no more RPM data - then you can see the signal generator approach pass 100khz around 1h 07m CPU load increases, and then the interrupt is not handled anymore until rebooted, saving the CubeBlack from reboot.

tested on:

ChipDes:
  family: STM32F42x
  revision: 3
Chip:
  20016419 STM32F42x_43x rev3 (no 1M flaw)
Info:
  flash size: 2080768
  board_type: 9 (fmuv3)
  board_rev: 0
Identification complete

Thank you, please pull the patch into master.