Hello,
I'm trying to get the BMP280 presure sensor from Bosch to work trough SPI at the i.MX 6UltraLite / 6ULL running kernel 4.9.88.
This is the part of my device tree:
&&ecspi4 {
fsl,spi-num-chipselects = <1>;
cs-gpios = <&gpio2 15 0>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_ecspi4_1>;
status = "okay";
// pressure sensor Bosch BMP280
bmp280@0 {
compatible = "bosch,bmp280";
reg = <0>;
#address-cells = <1>;
#size-cells = <0>;
spi-max-frequency = <500000>;
default-oversampling = <1>;
};
};
My config file looks like this:
CONFIG_BMP280=m
CONFIG_BMP280_SPI=m
This is the dmesg output:
[ 11.193138] bmp280 spi3.0: bad chip id: expected 58 got ff
[ 11.227348] bmp280: probe of spi3.0 failed with error -22
I triple-cheked the wiring before posting and the also I have a working setup with an Arduino using SPI.
Does anybody find what could cause the problem?
Thanks in advance,
Mathieu
Solved! Go to Solution.
Hello Igor,
Thanks for your answer. I took your advice and connected an oscilloscope. I saw that the CS signal was oscillating at a fixed frequency while performing a read/write operation. That's why it was returning 0xFF.
The solution lays in the pinmux where there was a conflict. This is the correct definition:
pinctrl_ecspi4_1: ecspi4grp {
fsl,pins = <
MX6UL_PAD_ENET2_TX_CLK__ECSPI4_MISO 0x100b1
MX6UL_PAD_ENET2_TX_EN__ECSPI4_MOSI 0x100b1
MX6UL_PAD_ENET2_TX_DATA1__ECSPI4_SCLK 0x100b1
MX6UL_PAD_ENET2_RX_ER__GPIO2_IO15 0x100b1
>;
};
Kind regards,
Mathieu
Hi Mathieu
one can try to debug it checking spi signals with oscilloscope and using
driver sources, starting with probe function :
bmp280-spi.c\pressure\iio\drivers - linux-imx - i.MX Linux kernel
May be helpful to check AN4553 Using Open Source Debugging Tools for Linux on i.MX Processors
https://www.nxp.com/docs/en/application-note/AN4553.pdf
Best regards
igor
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------
Hello Igor,
Thanks for your answer. I took your advice and connected an oscilloscope. I saw that the CS signal was oscillating at a fixed frequency while performing a read/write operation. That's why it was returning 0xFF.
The solution lays in the pinmux where there was a conflict. This is the correct definition:
pinctrl_ecspi4_1: ecspi4grp {
fsl,pins = <
MX6UL_PAD_ENET2_TX_CLK__ECSPI4_MISO 0x100b1
MX6UL_PAD_ENET2_TX_EN__ECSPI4_MOSI 0x100b1
MX6UL_PAD_ENET2_TX_DATA1__ECSPI4_SCLK 0x100b1
MX6UL_PAD_ENET2_RX_ER__GPIO2_IO15 0x100b1
>;
};
Kind regards,
Mathieu