Per the data sheet: Start-up time for register read/write from power-up is
Typically 11 ms and the Maximum is 100 ms.
It seems the power up reset is only triggered at VDD < 150 mV. So the
symptom reported: Failure is only happening after a long power down is
consistent with VDD not dropping below 150 mV, therefore not generating
a POR and being ready to be written with out delay.
This fix adds a delay of 110 ms to ensure the reset has ended with some.
margin.
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)
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.
MPU9250 is mostly an MPU6500 with a mag (AK8963) in the same package.
Support driving MPU6500 with the MPU9250 driver. The id of the driver
isn't set differently since this way it allows to force a recalibration.
Ideally MPU9250 driver could even not exist and the support for these
sensors be merged back in the MPU6000 that's more complete. This is an
intermediate step in that direction.
We propagate the bus parameters from the bus interface to the sensor
devices. Thus, the device ID of the sensor driver is set to the correct
bus id and address. Otherwise it would be zero, which is an issue if several MPU9250s
are running at the same time.
These headers files were missing from the header files that
I added them to; the fact that they were missing didn't
lead to compile errors because by coincidence the missing
headers are included in the source files before including
these headers. But, after the reordering of header inclusions
by Tools/fix_headers.sh, these cases will give rise to compiler
errors.
Daniel Agar