BMI270 interrupts seem not to be usable in nRF Connect SDK v2.2.0 with zephyr

[nfbe]

Hi,

I am developing a nrf5340 based board containing the BMI270 IMU device via SPI interface like in the Thingy:53.

Unfortunately I am not able to set the device up for using the data ready interrupt and reacting to the interrupt via the zephyr device driver so far. The device works fine just polling for values regularly, but I need it interrupt driven. Looking at the official zephyr project documentation, the interrupt interface simply does not seem to be implemented for BMI270.

Is there a simple example I could take a look at for implementing an interrupt driven approach using the interrupt lines of the BMI270 that e.g. to send a data ready interrupt (which the device could provide, if configured accordingly) and react by just reading the 16 bit values via SPI? I need the zephyr RTOS for other things in the code, but maybe there is a simple way of implementing the BMI270 interrupt interface without using the BMI270 zephyr driver?

How is the BMI270 interrupt line 1 (that is connected in the schematics) used in the thingy:53 software?

Any help is appreciated!

Regards,

Jens

nRF Connect SDK v2.2.0 on macOS Ventura 13.2.1, Apple M1 Pro
nrf5340 on custom board

[Elfving]

Hello Jens,

I will have to get back to you on this.

Regards,

Elfving

[Elfving]

Hello again, and thank you for your patience. 

First of all for some SPI interrupt examples, have a look here. 

The cleanest way would probably be to modify the sensor driver, but the easiest would be to add the interrupt pin as an interrupt GPIO, and when triggered add reading the sensor value using sensor_sample_fetch() to a workqueue.

How is the BMI270 interrupt line 1 (that is connected in the schematics) used in the thingy:53 software?

Which software are you referring to? I believe it might just be included so that you can use it if you want to, not that we need to use it in one particular use-case.

Regards,

Elfving

[nfbe]

Hi Elfving,

Thank you very much for your answer. I have thought of using the pins as you suggested before I wrote my post. But I hesitated, because BMI270 will not simply send interrupts, but needs to be configured to do so by setting registers via SPI. I have not tried yet, but I was assuming that I cannot combine the BMI270 driver with the zephyr SPI driver for the same device - or can I?

As for the Thingy:53 - I was only thinking that you might be using it in some way (or have tried using it), but I did not find any source on the net that uses this BMI270 interrupt line of the nrf5340 and the current device tree file you provide for the sdk does not show any entry for the interrupt (there is one for the first device, but the BMI270 is not set for interrupt in this tree).

&spi3 {
compatible = "nordic,nrf-spim";
status = "okay";
cs-gpios = <&gpio0 22 GPIO_ACTIVE_LOW>,
<&gpio1 4 GPIO_ACTIVE_LOW>,
<&gpio0 24 GPIO_ACTIVE_LOW>;

pinctrl-0 = <&spi3_default>;
pinctrl-1 = <&spi3_sleep>;
pinctrl-names = "default", "sleep";

adxl362: spi-dev-adxl362@0 {
compatible = "adi,adxl362";
spi-max-frequency = <8000000>;
reg = <0>;
int1-gpios = <&gpio0 19 0>;
};

bmi270: spi-dev-bmi270@1 {
compatible = "bosch,bmi270";
status = "disabled";
spi-max-frequency = <8000000>;
reg = <1>;
};

...

That was the reason for my question for a BMI270 example - I thought, maybe there might be something you plan to implement in the next version or you have some unofficial example code I could take a look at...

Now, what's left of my question is:

Do I have to abandon the BMI270 driver completely, if I need to use SPI communication to set registers in the device that is not supported by the device's driver, or can I mix drivers (pure SPI with the device specific one) on the same device? How would I configure that in the device tree?

Thanks for your comments.

Regards,

Jens

[nfbe]

Hi Elfving,
I took a look at the BMI270 driver code and used that device specific knowledge to write my own little functions to set the needed registers etc.. and I am using the Standard GPIO-interrupt as you suggested. So my code works for now. But still it would be great, if these functions would officially be exposed through the attributes you can set in the sensor driver in some later version of zephyr and the SDK.

Thanks a lot for your support. I think this ticket can be closed now.

Regards, Jens

[Elfving]

Great!

Glad to hear that it got solved, and I'll forward this request to the relevant people.

Regards,

Elfving