BMP280 support for i.MX 6UltraLite / 6ULL

[dezutter_mathie]

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

[igorpadykov]

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!
-----------------------------------------------------------------------------------------------------------------------

[dezutter_mathie · Accepted 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