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]

Q1:Can you please measure your voltage rails using a oscilloscope when this occurs, to see if the noise is also present on those?

Q2: Can you also measure the current of the whole system when the issue occurs?

 

Please share data from both scenarios.

 

Kind regards,

Håkon

[Bartosz22]

So here are the screens from oscilloscope, before and after the failure - the yellow is 3v3, the light blue is 1v8, the pink is SCK signal and dark blue is current on 5V line from wingboard. The NRF52840DK was connected to PC and the wingboard was powered from external power supply from 5V.
Before failure:



After failure:

There is a lot of noise on 3v3 and 1v8 lines. 

[Håkon Alseth]

Hi,

 

Thank you for providing the voltages and currents.

Bartosz22 said:

There is a lot of noise on 3v3 and 1v8 lines. 

The 3.3V and 1.8V line has over 0.5V ripple, if I read the scope picture correctly. This will highly likely cause unforeseen issues with anything connected on this voltage net. I would strongly recommend that you add decoupling, and possibly look into the regulator on this specific voltage net, to see if it is indeed able to deliver such an amount of current.

Where is the 3.3V and 1.8V generated/sourced from? And how does the overall path look like? 

 

Kind regards,

Håkon

[Bartosz22]

Yes, it has a ripple of over 0.5V. The 3.3V and 1.8V rails are part of the Infineon wingboard and are generated by an LDO, meaning they are not part of our design or NRF52840DK. On our custom hardware, we follow Infineon's design and recommendations, so the issue is the same. However, why does this problem only occur when BLE is enabled? Without BLE, we can't reproduce the issue. The wingboard is powered by a separate lab power supply, so there should be no influence from the NRF52840DK or any other external factors. If there were a voltage issue, I would expect the problem to occur consistently. However, it only happens when BLE is enabled.

[Håkon Alseth]

Bartosz22 said:

If there were a voltage issue, I would expect the problem to occur consistently.

Please look into adding capacitors on your LDO rails, to ensure that the ripple is left to a minimal level. Ripple on your supplies can cause noise on subsequent connected devices.

As previously mentioned, a 25 MHz source is not present inside the nRF, so the noise source is likely not the nRF.

  

Kind regards

Håkon