An input pin is flooded with pulses and has been switched off
What ArduPilot says:
- Pin N disabled (ISR flood)
- Retrying pin N after ISR flood
- ISR flood on pin N
Some inputs (an RPM sensor, a PWM rangefinder, the camera's feedback wire, a button) wake the processor at every edge of their signal. The pin named in the message produced more than 10 000 edges in 100 ms, enough to starve everything else, so ArduPilot stopped listening to it (“ISR flood on pin N”). While disarmed it tries again every 10 seconds (“Retrying pin N…”), and arming is refused while the pin is off.
What to do, most likely first
A pin is set up as an input but nothing is wired to it, so it picks up noise.
CheckLook for the pin number from the message in
RPM1_PIN,RNGFND1_PIN,CAM1_FEEDBAK_PINand the BTN_PINn parameters.FixSet the pin parameter of the feature you do not use to -1 and reboot.
The signal wire runs next to motor or ESC wires, or the sensor has no common ground with the board.
CheckThe flood starts when the motors run or the battery is connected, not on USB alone.
FixReroute or shield the wire and connect the grounds.
The signal is too fast for this kind of input.
FixUse a source ArduPilot can read another way: RPM from ESC telemetry instead of a pulse pin.
If the flood happens while armed, the pin stays off until after the flight and the internal error “gpio_isr” is raised as well.
Parameters to look at
| Parameter | What it is |
|---|---|
RPM1_PIN | Input pin number |
RNGFND1_PIN | Rangefinder pin |
CAM1_FEEDBAK_PIN | Camera feedback pin |
BTN_PIN1 | First button Pin |
Where to do it:Board & Wiring Planner
The code that sends it
Pin N disabled (ISR flood)
libraries/AP_HAL_ChibiOS/GPIO.cpp GPIO::arming_checks() · Open in ArduPilot Copter-4.7.1
Retrying pin N after ISR flood
libraries/AP_HAL_ChibiOS/GPIO.cpp GPIO::timer_tick() · Open in ArduPilot Copter-4.7.1
ISR flood on pin N
libraries/AP_HAL_ChibiOS/GPIO.cpp GPIO::timer_tick() · Open in ArduPilot Copter-4.7.1