Skip to content

Accelerometer MC3419 driver issue in setting Output Data Rate (ODR) #89326

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.

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

Open
jpdoyon opened this issue Apr 30, 2025 · 2 comments
Open

Accelerometer MC3419 driver issue in setting Output Data Rate (ODR) #89326

jpdoyon opened this issue Apr 30, 2025 · 2 comments
Assignees
Labels

Comments

@jpdoyon
Copy link

jpdoyon commented Apr 30, 2025

MC3419 datasheet states, in section 12.5 (0x08) SAMPLE RATE REGISTER that Bit 3 must be written as 1 (note 2: Software must write a one (1).)

Driver file zephyr/drivers/sensor/mc3419/mc3419.h, line 43 specifies a base value for the ODR value of 0x10 ( BIT(4) ). This is then added with the selected ODR value returned by mc3419_get_odr_value(...) in zephyr/drivers/sensor/mc3419/mc3419.c at line 136 to yield the value that will be written to register MC3419_REG_SAMPLE_RATE (0x08).

As hinted to above, that actually sets bit 4, not bit 3, causing the write to silently fail (the write is acknowledged, but the value isn't written because it is invalid).

This bug was found on the following release:

commit 36940db (HEAD, tag: v3.7.0, manifest-rev)
Author: Alberto Escolar Piedras alberto.escolar.piedras@nordicsemi.no
Date: Thu Jul 18 10:13:57 2024 +0200

release: Zephyr v3.7.0

Set the version to v3.7.0

Signed-off-by: Alberto Escolar Piedras <alberto.escolar.piedras@nordicsemi.no>
Copy link

Hi @jpdoyon! We appreciate you submitting your first issue for our open-source project. 🌟

Even though I'm a bot, I can assure you that the whole community is genuinely grateful for your time and effort. 🤖💙

@jpdoyon
Copy link
Author

jpdoyon commented Apr 30, 2025

Ok, seems like I jumped th gun on this one... I actually had a decimation issue, which was preventing the interrupts from being generated...

While the bug is valid (there is a mistake in the driver), it doesn't actually have any effect, which is why nobody ever noticed it before.

Sorry for the clutter...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants