Nano locks up if PWM sent to disabled Receiver Port pin 1


The issue is that Nano (at least) locks up if active PWM signal is sent to FC Receiver Port pin 1 when Receiver Port is unconfigured.

To recreate, flash Nano and erase settings. Connect an active PWM signal to Receiver Port. Power up (at least with battery it happens).

I used a Frsky D4R2 receiver configured for PPM mode. It supposedly puts out an RSSI PWM signal on a connector. Nano requires pin 2 for PPM, but Nano wiring has pin 1 connected with + and - and other pin connectors are only signal, so the easy way is to connect FC connector with pin1 (with + and -) to RSSI PWM connector on receiver and FC connector with pin 2 to PPM.

In this configuration, when you connect battery power (whether booted (successfully) with USB first or trying to boot with battery power (fails)) the Nano locks up but not in the bootloader. If USB is plugged in too, you can unplug battery and it continues on as if nothing happened. In all cases it works fine if there is no battery and fails if there is a battery.

Note that if booting from battery, the blue LED blinks quickly once and it locks up. That sounds like the BL is working. It also locks up in firmware if booted on USB and you add a battery later, so it isn't just a bad bootloader.

You can even remove the PPM wire, leaving only the PWM RSSI connected to pin 1, and the issue still happens.

Note that this is with the transmitter switched off, so the RSSI signal may be all the way to the low signal strength side. I recall seeing something about the min and max PWM RSSI pulse width and I recall that it is out of specification for a servo signal, something like 1% to 99% duty cycle.

I only have one Nano (so I can't test a second one to see if it is a hardware issue), but I will try to recreate this with Revo.


Linux64 Mint 17.2?
Testing a branch I based on 1509+R434
GCS version: 20160222 22:38 (96ed1e40-773f1d19)








Fix versions

Affects versions

REL-15.09 - Supermoon Eclipse