This change first pushes out the _reset_wait by 100 Ms.
which is about 3 time longer then the code take to execute.
Then it does the reset of the accel, gyro and mag and
the ends the wait by setting _reset_wait to now+10 us.
The MPU9250 and MPU6500 buth support 1 Mhz and 20 Mhz. Buy upping the clocc we will get the maximum clock rate the driver
supports that is <= 20 Mhz. This will boost the FMUv4Pro SPI speed to 11.25 Mhz (it was half that)
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.
This commit fixed a bug were the mag was orphened on a reset.
That resulted in MAG timeouts on reset or test operations and
left the mag in a broken state.
We want to setup the mag interface with retries and report
failurs.
Move retry logic to contol point, instead of hiding re-reading
the ID in ak8963_check_id.
Allow it to fail once to overcome a read of 0 on firt read.
after 2 failure report error to console and reset the
mpu9250's I2C master (SPI to I2C bridge)
The same retry logic is used on the ak8963_read_adjustments
with a reset of the I2C master module after 5 fails. If it
fails fter 10 retires. Disabel the mad and report the failure
on the console, stating it is disabled.
On initialization, if after 3 retries to re-init the mpu9250 from
the checked registers values, it fails. Ensure thath the fact the
driver is exitting is logged to console.
Check that the mpu9250's configured registers match the settings
written to them. Attempt to fix any that do not up to 3 times.
printing erros to the console on mismatches and returning
faliure if after 3 attempts the any of the values are
still wrong.
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.
This backports upstrem NuttX
ea7b673 - Allow dma in 1 bit mode in STM32F4xxx
17cbec1 - fix warning from ea7b673
4795d58 - Only the decoded.oid = (cid[0] >> 8) change.
Thanks to Jussi Kivilinna
https://bitbucket.org/nuttx/nuttx/commits/9169ff6a15fe65ba4af134b470dbf89220274c19
stm32_serial: fix freezing serial port. Serial interrupt enable/disable functions
do not disable interrupts and can freeze device when serial interrupt is received
while execution is at those functions.
Trivially triggered with two or more threads write to regular syslog stream and to
emergency stream. In this case, freeze happens because of mismatch of priv->ie
(TXEIE == 0) and actually enabled interrupts in USART registers (TXEIE == 1),
which leads to unhandled TXE interrupt and causes interrupt storm for USART.
Filter for channel 4 was modifying channel 1
capture and overflow reads were using wrong paramaters
in macros and addressing junk in memory.
up_input_capture_get_filter was shifing results the wrong way.
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.
The ramtron driver already calls SPI_LOCK when accessing the
FRAM.
Removed the interrupt lockout and anabled the SPI_LOCK
in the ms5611 driver on any HW where the
PX4_SPI_BUS_BARO == PX4_SPI_BUS_RAMTRON
Prior to onshot being added to the system. The -r of the
"rate" command would not invoke the ioctl PWM_SERVO_SET_UPDATE_RATE
when -r was not provided on the command line. This may have been a
feature or a bug.
When onshot was added to the pwm command a bug was intorduced
that precluded the ioctl PWM_SERVO_SET_UPDATE_RATE from being
called on -r 0.
This commit fixes that issue, and preserves the "prio to oneshot"
behavior of the "rate" command when -r is not specified.
sched_note_{suspend|resume} were calling hrt_absolute_time before
it hrt_init is called. This can lead to register access before
clocking is enabled. The result is a hardfault.
Ultimate we want this changes that is being backed out herein.
But it is breaking things because it returns the EINVAL
when there is a rate overlap. So the rest of the pwm ioctl
calls then fail and do not set the pulse widths on arming.
As a secondary issue. We sould call up_pwm_servo_init() to
establish the PWM channel allocation early. This then allows
FMU::set_pwm_rate to properly check for improper rate request
not isolate to one group (timer).
The root cause was the replacment of a local variable num_outputs
with the class member _num_outputs.
The effect of a "bad mix" is to return 0 - this clampped the
_num_outputs to 0.
Prior to commit 3b3e2b2 px4fmu: "consolidate usage of output mode"
this would not have been an issue because the local num_outputs
was reset every cycle"
As a secondary issue. We sould call up_pwm_servo_init() to
establish the PWM channel allocation early. This then allows
FMU::set_pwm_rate to properly check for improper rate request
not isolate to one group (timer).
The Make.defs compisition is
ARCHWARNINGS = $(PX4_ARCHWARNINGS)
ARCHCWARNINGS = $(PX4_ARCHWARNINGS) $(PX4_ARCHCWARNINGS)
ARCHWARNINGSXX = $(ARCHWARNINGS) $(PX4_ARCHWARNINGSXX)
so the pieces from nuttx-configs/PX4_Warnings.mk should not be combined.
While the list was sorted, this change serialize the application
of the patches.
Moved the disply to the actual application of the patch not
the configuration step.
The recent changes to the timers increased memory by 8 bytes.
and should have ONLY added 8 bytes
was 20000dc0 40 20000E00
is: 20000dc8 40 20000E08
s/b 20000E08 1f3 next symbol
But for some unknown reason the linker skipped to the next alignment
of 256 and wasted 246 bytes.
20000F00 1f3 next symbol
Even with .align 8 in the .S file and . = ALIGN(4); in the linker
script I could not move the allocation back only up to the next
512 alighment.
So this is a hack to shift things back 8 bytes.
* NSH Added support for set [{+|-}{e|x|xe|ex}] [<name> <value>]
Set the 'exit on error control' and/or 'print a trace' of
commands when parsing scripts in NSH.
The settinngs are in effect from the point of exection,
until they are changed again, or in the case of the init
script, the settings are returned to the default settings
when it exits.
Included child scripts will run with the parents settings
and changes made in the child script will effect the parent
on return.
Use 'set -e' to enable and 'set +e' to disable (ignore) the exit
condition on commands. The default is -e. Errors cause script to
exit.
Use 'set -x' to enable and 'set +x' to disable (silence) printing
a trace of the script commands as they are ececuted. The default
is +x. No printing of a trace of script commands as they are
executed.
Print expanded variables if -x
* Added comments only on how to use the set +e and and set -x
* Spelling NSH_PFALG_* -> NSH_PFLAG_*
This fixes the issue with initializing channels 5,6 without
channels 1-4.
The code assumed all timers actions were in order to be
initialized. This is not the case. This commit fixes that
bad assumption by not stopping the configuration on the
first action entry with a base == 0, but processing all
entries with non-zero base.
1) Revert the inherited dma bug from the stm32
see https://bitbucket.org/nuttx/nuttx/commits/df9ae3c13fc2fff2c21ebdb098c520b11f43280d
for details.
2) Most all CR1-CR3 settings can not be configured while UE
is true. Threfore we make all operation atomic and disable
UE and restore it's originalstate on exit.
N.B. This backport omits all upstream breaking changes.
FMUv4 PRO HW does not have a controlable V3.3 on the connector
it therefore can not support the SPEKTUM binding.
This PR removes the Power switch controls or binding control
interfaces from the board config
Removed the legacy FMUv4 define that was activating a nonexistent
pull up and on some HW driving the PPM_IN aka RC_IN aka SPEKTRUM_RX
to VDD.
Also detailed the connections of this pins for the board.
The simplest connection is RC_IN to a timer capture pin
and a UART.
In this case the UART_RX pin and just be left as is.
While the pin can be configured as the PPM_IN (Timer capture)
or as SPEKTRUM_RX_AS_GPIO_OUTPUT to use it as and GPIO to
facilitate binding.
Renamed the macros and defines to be more explicit as to what
Is being done and the sense of the parameters
Removed the legacy FMUv4 define that was activating a nonexistent
pull up and on some HW driving the PPM_IN aka RC_IN aka SPEKTRUM_RX
to VDD.
Also detailed the connections of this pins for the board.
The simplest connection is RC_IN to a timer capture pin
and a UART.
In this case the UART_RX pin and just be left as is.
While the pin can be configured as the PPM_IN (Timer capture)
or as SPEKTRUM_RX_AS_GPIO_OUTPUT to use it as and GPIO to
facilitate bindin
Renamed the macros and defines to be more explicit as to what
Is being done and the sense of the parameters
Removed the legacy FMUv4 define that was activating a nonexistent
pull up and on some HW driving the PPM_IN aka RC_IN aka SPEKTRUM_RX
to VDD.
Also detailed the connections of this pins for the board.
The simplest connection is RC_IN to a timer capture pin
and a UART.
In this case the UART_RX pin and just be left as is.
While the pin can be configured as the PPM_IN (Timer capture)
or as SPEKTRUM_RX_AS_GPIO_OUTPUT to use it as and GPIO to
Renamed the macros and defines to be more explicit as to what
Is being done and the sense of the parameters
Removed the legacy FMUv4 define that was activating a nonexistent
pull up and on some HW driving the PPM_IN aka RC_IN aka SPEKTRUM_RX
to VDD.
Also detailed the connections of this pins for the board.
The simplest connection is RC_IN to a timer capture pin
and a UART.
In this case the UART_RX pin and just be left as is.
While the pin can be configured as the PPM_IN (Timer capture)
or as SPEKTRUM_RX_AS_GPIO_OUTPUT to use it as and GPIO to
facilitate binding.
Renamed the macros and defines to be more explicit as to what
Is being done and the sense of the parameters
Removed the legacy FMUv4 define that was activating a nonexistent
pull up and on some HW driving the PPM_IN aka RC_IN aka SPEKTRUM_RX
to VDD.
Also detailed the connections of this pins for the board.
The simplest connection is RC_IN to a timer capture pin
and a UART.
In this case the UART_RX pin and just be left as is.
While the pin can be configured as the PPM_IN (Timer capture)
or as SPEKTRUM_R
facilitate binding.
Renamed the macros and defines to be more explicit as to what
Is being done and the sense of the parameters
Removed the legacy FMUv4 define that was activating a nonexistent
pull up and on some HW driving the PPM_IN aka RC_IN aka SPEKTRUM_RX
to VDD.
Also detailed the connections of this pins for the board.
The simplest connection is RC_IN to a timer capture pin
and a UART.
In this case the UART_RX pin and just be left as is.
While the pin can be configured as the PPM_IN (Timer capture)
or as SPEKTRUM_RX_AS_GPIO_OUTPUT to use it as and GPIO to
facilitate binding.
Renamed the macros and defines to be more explicit as to what
Is being done and the sense of the parameters
Removed the legacy FMUv4 define that was activating a nonexistent
pull up and on some HW driving the PPM_IN aka RC_IN aka SPEKTRUM_RX
to VDD.
Also detailed the connections of this pins for the board.
The simplest connection is RC_IN to a timer capture pin
and a UART.
In this case the UART_RX pin and just be left as is.
While the pin can be configured as the PPM_IN (Timer capture)
or as SPEKTRUM_RX_AS_GPIO_OUTPUT to use it as and GPIO to
facilitate binding.
Renamed the macros and defines to be more explicit as to what
Is being done and the sense of the parameters
Removed the legacy FMUv4 define that was activating a nonexistent
pull up and on some HW driving the PPM_IN aka RC_IN aka SPEKTRUM_RX
to VDD.
Also detailed the connections of this pins for the board.
The simplest connection is RC_IN to a timer capture pin
and a UART.
In this case the UART_RX pin and just be left as is.
While the pin can be configured as the PPM_IN (Timer capture)
or as SPEKTRUM_RX_AS_GPIO_OUTPUT to use it as and GPIO to
facilitate binding.
Renamed the macros and defines to be more explicit as to what
Is being done and the sense of the parameters
Removed the legacy FMUv4 define that was activating a nonexistent
pull up and on some HW driving the PPM_IN aka RC_IN aka SPEKTRUM_RX
to VDD.
Use the abstaction SPEKTRUM_POWER to enable the interface not
the define for the GPIO pin.
Removed the legacy FMUv4 define that was activating a nonexistent
pull up and on some HW driving the PPM_IN aka RC_IN aka SPEKTRUM_RX
to VDD.
Also detailed the connections of this pins for the board.
The simplest connection is RC_IN to a timer capture pin
and a UART.
In this case the UART_RX pin and just be left as is.
While the pin can be configured as the PPM_IN (Timer capture)
or as SPEKTRUM_RX_AS_GPIO_OUTPUT to use it as and GPIO to
facilitate binding.
Renamed the macros and defines to be more explicit as to what
Is being done and the sense of the parameters
Returned the fmu mixer code to where it updated the HW once
it has a mixer. But only signals a up_pwm_update() for
onshots on actual control update.
Before this change the hw outpuse were not updated.
A recent change in in the fmu stops the instance when a
xxxx_reset command is used issued if the fmu was not
already running.
That change left publications published and then on the
next creation created a new publications was created.
This change calls orb_unadvertise to mark the publication
as un published so that on the next instantiations of the
fmu it resumes publishing on the same publication.
* stm32 Updated flash patch to upstream (fixes missing commit)
* Removed zubaxgnss-v1_bootloader check build will not fit
Removing zubaxgnss-v1_bootloader from the check build. It is overflowing flash by 6 Bytes.
Recent upsteam NuttX changes needed by PX4 added sem_[wait|post]
in the stm32_flash driver.
UAVCAN Bootloaders do not use the OS's scheduler etal.
This commit nops the sem_[wait|post] with linker magic.
Which precludes the linking the nuttx scheduler in the
bootloader build.
PX4 contrib from <jose.souza@intel.com>
1) stm32: Fix erase sector number for microcontrolers with
more than 11 sectors
Erase a sector from the second bank cause the bit 4 of SNB being set
but never unsed, so trying to erase a sector from the first bank
was acually eraseing a sector from the second bank.
2) stm32: Make up_progmem thread safe
Writing to a flash sector while starting the erase of other sector
have a undefined behavior so lets add a [staticaly initalized]
semaphore and syncronize access to Flash registers.
3) Add workaround for flash data cache corruption on
read-while-write
This is a know hardware issue on some STM32 see the errata
of your model and if you make use of both memory banks you
should enable it.
4) Greg's cleanup
5) PX4 clean up
stm32_flash:Need conditional on non F4 targets
* Order patch application
Per discussion with @demarchi this PR adds ordering to the
patch application.
This alos add some encoding
00000 series - is for px4 non up streamable changes
60000 (bp) series - is for back ports
90000 series - is for wip that shold make it upstream
* Restore 00010-workarround-for-flash-data-cache-corruption
Extract this from the 90000-wip-inflight-to-upstream.patch
and orders it.
* Moved upstreamed 0dbf44e flash fix to bp patch
* Moved upstreamed 5481087 cdcacm fix to bp patch
* Moved upstreamed ec85425 STM32F7 copy paste errors to bp patch
* Moved upstreamed 20e7237 HSI should not be turned off to bp patch
* Moved upstreamed ca895b9 Adding missing CONFIG_ prefix to bp patch
* Moved upstreamed 169b398 STM32: Fixes the bkp reference counter issue to bp patch
* Moved upstreamed 550d259 STM32F7: Fixes the bkp reference counter issue to bp patch
* Moved upstreamed 02825f3 STM32F3X: Add missing STM32_BKP_BASE to bp patch
* Renamed for ordering and classification
* Renamed for ordering and classification
* Renamed for ordering and classification
* Renamed for ordering and classification
* Renamed for ordering and classification
* Renamed for ordering and classification
* Renamed for ordering and classification
* Renamed for ordering and classification
* Renamed for ordering and classification
* Renamed for ordering and classification
* Renamed for ordering and classification
* Renamed for ordering and classification
* Renamed for ordering and classification
* Renamed for ordering and classification
* Renamed for ordering and classification
* Renamed for ordering and classification
* Renamed for ordering and classification
* Renamed for ordering and classification
* Renamed for ordering and classification
* Renamed for ordering and classification
* Renamed for ordering and classification
* Renamed for ordering and classification
* Renamed for ordering and classification
* Renamed for ordering and classification
* Order Patches by Name
This reverts commit 22738b1213fff704d288ec84976fa84ff9535aba.
The command was added due to a lack of my understanding of how the pwm command can be used.
The command is not needed as the all flag can be used or a proper
mask WHIHOUT -g
fmu task mode_pwm
pwm rate -a -r 50 -d /dev/pwm_output0
pwm arm
pwm test -a -p 500
fmu task mode_pwm
pwm oneshot -a -d /dev/pwm_output0 is the same as pwm oneshot -m 0xff -d /dev/pwm_output0
pwm arm
pwm test -a -p 500
David Sidrane