SPIM3 and interrupts

[Bartosz22]

Hi,

I encountered an issue with SPIM3 and interrupts while using the NRF52840 with an Infineon sensor. The sensor generates an interrupt every 54-55ms, after which I read data via SPI. I chose SPIM3 for its high-speed capability and set the SPI clock to 24MHz.

However, after some time, I observed unexpected behavior on the interrupt line—rather than a single interrupt, I saw three consecutive interrupts occurring in quick succession. It appears that these extra interrupts are not coming from the sensor but are instead being generated on the MCU side. This pattern persists for a while before returning to normal.

When I switched to SPIM2 and reduced the SPI clock speed to 8MHz because this SPI intances oesn't handle high speed clock, the issue disappeared. Could there be a known problem with SPIM3 causing this behavior? I'm using the latest SDK (2.9) with BLE enabled. The errata mention issues with SPIM3 and events—could these be responsible for the problem I'm experiencing?

[Håkon Alseth]

Hi,

 

I am glad to hear that the issue disappeared, but it might just be masked by the fact that the speed was lowered.

However, after some time, I observed unexpected behavior on the interrupt line—rather than a single interrupt, I saw three consecutive interrupts occurring in quick succession. It appears that these extra interrupts are not coming from the sensor but are instead being generated on the MCU side. This pattern persists for a while before returning to normal.

Q1: Could you show, with logs, what the behavior is?

Q2: Is this a IRQ-pin from the sensor itself? Can you also share how you set this up, in device tree?

 

Kind regards,

Håkon

[Bartosz22]

This is my configuration of SPI:

&pinctrl {
    spi3_default: spi3_default {
        group1 {
            psels = <NRF_PSEL(SPIM_SCK, 0, 7)>,
                    <NRF_PSEL(SPIM_MOSI, 1, 8)>;
            nordic,drive-mode = <NRF_DRIVE_H0H1>;
        };
        group2 {
            psels = <NRF_PSEL(SPIM_MISO, 0, 8)>;
            bias-pull-up;
            nordic,drive-mode = <NRF_DRIVE_H0H1>;
        };
    };

    spi3_sleep: spi3_sleep {
        group1 {
            psels = <NRF_PSEL(SPIM_SCK, 0, 7)>,
                    <NRF_PSEL(SPIM_MOSI, 1, 8)>;
            low-power-enable;
            nordic,drive-mode = <NRF_DRIVE_H0H1>;
        };
        group2 {
            psels = <NRF_PSEL(SPIM_MISO, 0, 8)>;
            bias-pull-up;
            nordic,drive-mode = <NRF_DRIVE_H0H1>;
        };
    };
};

&spi3 {
    compatible = "nordic,nrf-spim";
    status = "okay";
    pinctrl-0 = <&spi3_default>;
    pinctrl-1 = <&spi3_sleep>;
    pinctrl-names = "default", "sleep";
};

And I set the frequency of SPI to 24MHz. In prj.conf I also set CONFIG_NRFX_SPIM3=y.


The interrupt pin looks like this:

bgt60utr11aip-irq-gpios = <&gpio0 14 (GPIO_ACTIVE_HIGH | GPIO_PULL_DOWN)>;

And initialization:
static const struct gpio_dt_spec Irq =
    GPIO_DT_SPEC_GET(DT_PATH(zephyr_user), bgt60utr11aip_irq_gpios);
    
if (gpio_is_ready_dt(&Irq)) {
    if (0 != gpio_pin_configure_dt(&Irq, GPIO_INPUT)) {
        return (false);
    }
    gpio_pin_interrupt_configure_dt(&Irq, GPIO_INT_EDGE_RISING);
    gpio_init_callback(&IrqCb, irq_handler, BIT(Irq.pin));
    gpio_add_callback(Irq.port, &IrqCb);
}

After changing it to SPI2 problem still exists but after longer time.

[Håkon Alseth]

Hi,

 

It seems that you are not initializing the gpio with your wanted flags.

Could you try adding (GPIO_INPUT | GPIO_PULL_DOWN) to this line?

if (0 != gpio_pin_configure_dt(&Irq, GPIO_INPUT))

 

Kind regards,

Håkon

[Bartosz22]

Ok, I will try that and we will see the results.

[Håkon Alseth]

Sounds good. Let me know how the testing goes.

 

Kind regards,

Håkon

[Bartosz22]

The problem still occurs, what I debug is after some time I get error with wrong clock number from the sensor which means that SPI clock number does not match the expected number of clock cycles. 

[Bartosz22]

Disabling BLE seems to improve the issue, though I'm unsure for how long. Tomorrow, I'll check the oscilloscope and analyze the SPI signals. With disabled BLE I didn't see the issue for now.