Moving forward we want all the board configs to drive the
configuration. This is just cleanup to give a clear
example of how ADC should be defined by a simple list,
based on ADC pin number as related to the GPIO and
channel number. Then the xxx_CHANNEL bit are
used to form the ADC_CHANNELS (mask). The GPIO
will are used to for a list for initalization.
This prevents the compiler from optimising pdump. The error was:
Firmware/src/drivers/boards/common/board_crashdump.c:41:2: error: 'memset' writing 3240 bytes into a region of size 4 overflows the destination [-Werror=stringop-overflow=]
memset(pdump, 0, sizeof(fullcontext_s));
previously, get_devname() was used as the I2C device path, but on NuttX,
get_devname() is the device file which the driver creates. This patch
changes it, so the sematics are the same as on NuttX: both now use _bus
to decide to which I2C bus device to talk to.
I did not see any other use-cases than the led on ocpoc.
Insure a 0.0 voltage initial condition on VDD_3V3_SENSORS
By starting the GPIO_VDD_3V3_SENSORS_EN, low and deferring
the GPIO init of the slave selects and drdy signals until
board_app_initialize. We get ~ 180 ms of power off time
with 0.00 voltage applied to the sensors.
Given the original poster's comment that "It happens very consistently for us." I suspect the motor spin observed in https://github.com/PX4/Firmware/issues/7457 is not caused by the original issue of slow decay on the PWM pins at reset, but the post reset pulse of 3.1 Ms arriving in a window that the ESC considers it valid.
The results from testing, indicated that the if the PWM pins were clamped low for > 300 Ms, prior to reset the motors did not spin. This would delay the the post reset pulse of 3.1 Ms out by > 300 Ms.
This change delays the reset and therefore the pulse by at least 400 Ms.
problem: previously when connecting power to Power 1, commander refused
to arm (no power source error), and when connecting to Power 2, arming
works, but power consumption was not measured (& shown in QGC).
Swapping Brick1 with Brick2 makes sure both works when connecting to
power 1.
Ideally we will have support for both power sources (including fail-over)
When the CCER is cleared the IO pin tends to float. The FMUV4
HW has no TXS0108 and if cut off while high will decay.
By adding the pull down the pins will seek the low state faster.
13.8 us from off to decabe below threshold.
David Sidrane