Interrput line number configuration nRF5340

[Ben_Squar3d]

Hi, 

I faced some issues regarding multiple IRQ_CONNECT being onvoked on the same irq and I went into this post : 

LPUART nRF5340 fatal error - Nordic Q&A - Nordic DevZone - Nordic DevZone (nordicsemi.com)

Does it means that any <PERIPHERAL>X interrput can be re-routed to any <PERIPHERAL>Y line? 

For instance, I use TWIM0, and I assume following code is not valid : 

&i2c0 {
    compatible = "nordic,nrf-twim";
    status = "okay";
    pinctrl-0 = <&i2c0_default>;
    pinctrl-1 = <&i2c0_sleep>;
    pinctrl-names = "default", "sleep";
    // re-route to TWIM1 interrupt
    interrputs: <9 5>
};

What about replace &i2c0 by &i2c? I would need some clarification on this point, as the post doesn't really explain why moving GPIOTE0 interrupt line to GPIOTE1's one works.

Thank you in advance

[Turbo J]

If you read the PS carefully, you will see that multiple peripherials share address space. That includes the IRQ line.

You can only use one of the instances - either UART, SPIM,SPIS or TWI.

The UART0 is used by multiple examples, so try i2c1 or i2c2 in your dts or overlay file.

You can inspect the combined dts in the build/zephyr subdir, it should enable ("okay") only one of the peripherials with the same address.

[Ben_Squar3d]

Sorry, I should have been more precise. I know some peripherals share same address space : 

And I know that is why IRQ_CONNECT can only be called once per irq number/peripheral ID. My questions were : why does re-route GPIOTE IRQ to GPIOTE1 (47) instead of GPIOTE0 (9) work? In the same way, could I re-route IRQ of I2C0 (8) to I2C1 (9) ? Like GPIOTE0 and GPIOTE1, I2C0 and I2C1 doesn't share adderss space. Thank you

[Vidar Berg]

Ben_Squar3d said:

why does re-route GPIOTE IRQ to GPIOTE1 (47) instead of GPIOTE0 (9) work?

The problem discussed in linked Q&A seems to be about the application switching from using GPIOTE0 to GPIOTE1 after building the application for the Non Secure Processing Environment (i.e. nrf5340dk_nrf5340_cpuapp_ns). Therefore, the harcoded IRQ number had to be changed to match the selected peripheral. 

Could you provide a bit more information about what you are trying to achieve?

Best regards,

Vidar

[Ben_Squar3d]

Ok got it! I wondered if I could perform similar operation for other peripheral to workaround the limitation of TWIM0 OR SPI0 and TWIM1 OR SPI1 etc.. It seems not possible, thank you for you answer

[Vidar Berg]

I see, thanks for the clarification. Unfortunately, the Zephyr drivers does not support dynamic un-initialization and re-initialization of peripherals which would be required to allow shared usage of multiple peripherals with the same ID. This is however possible if you use the nrfx drivers directly as demonstrated by the nrfx peripheral resource sharing example.