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.

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

mpu9250 not starting on px4_fmu-v4 (and likely others) #11162

Closed
dagar opened this issue Jan 7, 2019 · 11 comments
Closed

mpu9250 not starting on px4_fmu-v4 (and likely others) #11162

dagar opened this issue Jan 7, 2019 · 11 comments
Labels

Comments

@dagar
Copy link
Member

dagar commented Jan 7, 2019

This is likely more fallout from expanding the existing mpu9250 driver to support the icm20948 (#10116) and follow up fixes (#11020)

Noticed by Jenkins (http://ci.px4.io:8080/blue/organizations/jenkins/PX4_misc%2FFirmware-hardware/detail/pr-update_src%2Flib%2Fecl/70/pipeline/79/#step-102-log-53).

image

FYI @dakejahl @DanielePettenuzzo @flochir

@dagar dagar added the bug label Jan 7, 2019
@dagar dagar added this to the Release v1.9.0 milestone Jan 7, 2019
@dakejahl
Copy link
Contributor

dakejahl commented Jan 7, 2019

Do these buses have the mpu9250/6500/20948 on them? I noticed the driver was now trying to start on every bus and just failing if device not present.

@dagar
Copy link
Member Author

dagar commented Jan 7, 2019

That's an mRo pixracer on the hardware test rack with only an mRo GPS connected (https://store.mrobotics.io/mRo-GPS-u-Blox-Neo-M8N-HMC5983-Compass-p/mro-gps003-mr.htm), dronecode debug (SWD + serial console), and USB power.

@dakejahl
Copy link
Contributor

dakejahl commented Jan 7, 2019

Does that variant have the mpu9250 on i2c? That screenshot is of i2c start failing

@dakejahl
Copy link
Contributor

dakejahl commented Jan 7, 2019

Looks like the mpu9250 is started without a bus_id opt arg and thus it attempts to start on all busses.
https://github.com/PX4/Firmware/blob/master/boards/px4/fmu-v4/init/rc.board#L84-L89

@dakejahl
Copy link
Contributor

dakejahl commented Jan 7, 2019

Looks like the mpu9250 is indeed starting.
selection_014
selection_015
And bus 3 corresponds to MPU9250_BUS_SPI_INTERNAL

@dakejahl
Copy link
Contributor

dakejahl commented Jan 7, 2019

This is with a pixracer, not sure the version (not printed on the silk screen) but it's one of those little red boards

@flochir
Copy link
Contributor

flochir commented Jan 8, 2019

Omitting the bus on the driver call shouldn't cause a fail though, just a chance of starting an unintended device with maybe wrong parameters.

@dakejahl
Copy link
Contributor

dakejahl commented Jan 8, 2019

just a chance of starting an unintended device with maybe wrong parameters.

So yeah, it tries to start a device on all the busses, and then "fails" on each bus where there is no device present.

@flochir
Copy link
Contributor

flochir commented Jan 9, 2019

@dakejahl Ok, I see it now. I think that happens now because the probe() function of mpu9250_i2c.cpp was disabled in #11020. It gets called implicitly by interface->init() in line 232 of main.cpp. This way, the driver itself only got instanciated when the device was already detected, and a fail of init() actually meant a fail. Now that can also be caused by the device not being present.

@flochir
Copy link
Contributor

flochir commented Jan 9, 2019

Added a new whoami-based version of device probe in I2C interface probe to PR: #11173
@dagar @dakejahl Can you try if this fixes the issue?

@dagar
Copy link
Member Author

dagar commented Jan 9, 2019

Fixed by #11173

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

3 participants