PWM Start up states

[davids5]

@LorenzMeier, @kd0aij , @pkocmoud
When developing Add Input Capture capabilities to FMU I was scrutinizing the inital conditions on the FMU V2 HW, today I looked at the FMU V4 HW.

Here is FMUV2 on master

There are 3 things to note:

1. The AUX lines are high at start up.
2. The blip on chan 5
3. glitches on transition to PWM

I wanted to have the aux channels start low. So I changed the
#define GPIO_GPIOn_INPUT (GPIO_INPUT|GPIO_PULLUP|GPIO_PORTE|GPIO_PIN14)
to
#define GPIO_GPIO0_INPUT (GPIO_INPUT|GPIO_PULLDOWN|GPIO_PORTE|GPIO_PIN14)

On V2 hardware the inputs still were high. The reason I believe is the TXS0108E-Q1 8-Bit Bi-directional, Level-Shifting, Voltage Translator. When a B side input is connected to an input or left floating it wins over the A side pull down. (I attached a EMAX ES08A as a load and it still starts high)

Secondly The blip on Chan 5 is caused by this line of code. Does anyone know why this was added from here ?

The final issue I would like to share is the glitches on master when the gopio(s) transitions to PWM mode. Prior to the 1 Ms pulse.

Master:

Remedies

On Add Input Capture capabilities to FMU V2 HW has been reduced to one .1875 us glitch

Zoomed in:

This remaining glitch is caused by nuttx and I believe I can fix it for V2 HW - I just need to review the IO structure on the STM32 and the nuttx gpio config code to see if my solution is not going to add other problems..

On FMUV4 Hardware we can change to using #define GPIO_GPIO0_INPUT (GPIO_INPUT|GPIO_PULLDOWN|GPIO_PORTE|GPIO_PIN14)
and it will work to initialize from boot the AUX channels low.

Then on V4 HW there would be no glitches (except for #2) listed above. But that can be fixed easily.

[LorenzMeier]

@davids5 This line: https://github.com/PX4/Firmware/blob/master/src/drivers/boards/px4fmu-v2/px4fmu2_init.c#L236

Is because of Lidar PWM power control. But probably done in a wrong way and I'd like to factor it out.

[davids5]

@LorenzMeier,

Thanks for unraveling the mystery. Yes it is in the wrong place. The driver should use an IOCTL on the FMU or if it is time critical take ownership of the pin.

On a related note: I wonder it the statup code change from 2e8accc might have caused Lidar via PWM stopped working

[davids5]

@LorenzMeier - @tridge has a valid point about removing the default_value and replacing the init witn rCCRn(timer) = 0;

This will ensure a channel that is enabled and not configured will not begin an output of any pulse train.

[LorenzMeier]

I've already merged that. Can you rebase, strip that setting entirely and configure to 0? I will look tomorrow into the pin config for the 5th pin and into fitting that into this PR to put this all to rest.

[davids5]

@LorenzMeier - PR for just this change against master. #3632 pushed

[davids5]

@LorenzMeier Rebased #3607 to also use a default rate of 0
@tridge - these changes have been rebased at 7958dae

[LorenzMeier]

Fixed on master.