Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Adis16470 startup fixes #24185

Open
wants to merge 5 commits into
base: main
Choose a base branch
from
Open

Adis16470 startup fixes #24185

wants to merge 5 commits into from
+55 −30

Conversation

jlaitine
Copy link
Contributor

@jlaitine jlaitine commented Jan 8, 2025

This is a collection of patches for adis16470 driver from TII repository for the following issues:

  • DRDY interrupt is not working on all platforms; it works only on those which enable the interrupt regardless of the "event" parameter to the px4_arch_gpiosetevent call. The "event" should be set to "true" to enable the interrupt.
  • If there are errors in the startup sequence, the driver still published the data between IMU resets. This caused very low frequency data publishing initially, which locks the "sensors" module to run rate control at low frequency.
  • There are additional delays in the ADIS16470 sensor which are not specified in the datasheet. Basically delays between setting a register/writing a command to the action to start. These are reverse engineered with oscilloscope/logic analyzer and added to the driver
  • Before starting the self test after SW reset, there was no check that the IMU has woken up from the reset. Combined to the too small delays this caused the self-test command to be sent to inactive IMU, and reading back a 0 value which was again interpreted as "success".
  • The IMU requires > 1 us inactive CS period between register reads/writes. Again this is not specified in the datasheet, but was found via testing. This causes random erroneous register checks on faster CPU:s
  • The MSC_CTRL register check only checked if the Bit0 was read out as 0. If the register read returns whatever garbage, or the register value was changed to something strange, it was not detected - as long as the Bit0 was 0...

On faster CPUs there is still a need to ensure > 200ns CS to SCK delay to ensure stable operation, for that there is a draft PR #23905 . But that is an independent issue which most likely doesn't show on any slower (i.e. existing commercial) devices.

@jlaitine
ADIS16470: Enable DRDY interrupt
a1b4b22 
The call to px4_arch_gpiosetevent didn't set the "event" flag to "true".
Some platforms just ignore this flag and always enable the event, which
is the reason that this happened to work on those.

Signed-off-by: Jukka Laitinen <[email protected]>
@jlaitine
ADIS16470: Publish data only when there are no failures
8ef9fb3 
Publishing data also in error cases may cause irregular rate at bootup, leading to wrong
sample rate detection in "sensors" module

Signed-off-by: Jukka Laitinen <[email protected]>
@jlaitine
ADIS16470: Fix reset and self-test sequence
c9a6b42 
Fix issues related to unspecified delays in the ADIS sensor:

1. The reset occurs only after some delay from writing the SW reset, and the 193ms
mentioned in the datasheet occurs only after that. When the reset sequence really
starts can be determined with logic analyzer by monitoring DR signal and SPI writes.
This delay is measured to be between 10-20ms, so add 20ms to SW reset recovery time.

2. The self test sequence starts only after some delay from writing the command, and the
14ms mentioned in the datasheet starts only after this delay. Again, the behaviour can be
studied with logic analyzer by monitoring the DR signal and the SPI writes - when the self
test is completed, the IMU starts measuring again and the DR starts toggling. This
unspecified delay is measured to be somewhere between 5-10ms, so add 10ms to self test time.

3. After writing the register set in Configure(), there is an unspecified delay before the
register can be read back. This was bisected to be around 50us, so add 100us delay after
setting the registers before trying to read them back.

In addition:
1. Make sure that the IMU has woken up after reset by reading the PROD_ID register
always after the reset, also before starting the self test sequence on the first boot.
2. If self test fails, reset the IMU as a false result may occur due to moving the device
during self test (according to the datasheet).

Signed-off-by: Jukka Laitinen <[email protected]>
@jlaitine
ADIS16470: Ensure long enough CS-to-CS delay in consecutive RegisterR…
a666e96 
…ead and RegisterWrite calls

Add a 1us delay before register read and register write. It is not specified in the datasheet,
but it has been found via testing & oscilloscope measurements that > 1us inactive phase
is required between reads and writes.

Signed-off-by: Jukka Laitinen <[email protected]>
@jlaitine
ADIS16470: Explicitly write & check all bits in MSC_CTRL register
ef3ef60 
In case of any register read/write errors it is not enough to just check if
one of the bits is 0; the whole register contents needs to be checked. Also,
if initial read of the register fails in any reason, we should not write
back some corrupted value such as 0 or 0xFFFE.

Signed-off-by: Jukka Laitinen <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
1 participant
@jlaitine