LPUART nRF5340 fatal error

RE: LPUART nRF5340 fatal error

Øivind — Mon, 05 Jun 2023 12:53:40 GMT

https://github.com/nrfconnect/sdk-hal_nordic/blob/main/nrfx/mdk/nrf5340_application.h#L53-L114

13 is the irq number for GPIOTE0, while 47 is the irq number for GPIOTE1. There is a hard split between the two when it comes to secure and non-secure regions, where GPIOTE0 is only secure and GPIOTE1 is only non-secure.

https://infocenter.nordicsemi.com/index.jsp?topic=%2Fps_nrf5340%2Fgpiote.html&cp=4_0_0_6_13

RE: LPUART nRF5340 fatal error

Chris Burns — Fri, 02 Jun 2023 16:19:37 GMT

That change works. Now the LPUART and other GPIO interrupts work with the board_cpuapp_ns build target.

Why does using interrupt 47 work when 13 didn't? I don't know where to find the information about how to set the GPIOTE interrupts in the DTS.

Thanks for your help.

RE: LPUART nRF5340 fatal error

Øivind — Fri, 02 Jun 2023 12:25:25 GMT

Hi, can you try using 47 instead of 13 for the gpiote interrupt?

RE: LPUART nRF5340 fatal error

Øivind — Thu, 25 May 2023 11:52:51 GMT

I have not found a configuration setup that solves the issue, but I agree that TF-M is likely the culprit. I have opened an issue internally and will keep you updated as it progresses.

RE: LPUART nRF5340 fatal error

Chris Burns — Tue, 23 May 2023 19:23:36 GMT

I discovered that the GPIOTE ISR is called if I compile for board_cpuapp instead of board_cpuapp_ns. It seems there's an issue using GPIOTE interrupts in the app and TF-M. Is there a config option to fix this?

RE: LPUART nRF5340 fatal error

Øivind — Tue, 23 May 2023 12:30:09 GMT

I haven't found a likely solution yet, unfortunately.

Could you test the lpuart sample at nrf/samples/peripheral/lpuart on the nrf5340 on the custom board? Do not use the overlay in the sample, use your own overlay instead. How are the results then?

RE: LPUART nRF5340 fatal error

Øivind — Fri, 19 May 2023 12:48:30 GMT

We have been short staffed this week due to Public Holidays in Norway. I will be back on Monday with an update. I am sorry for the inconvenience.

RE: LPUART nRF5340 fatal error

Chris Burns — Fri, 12 May 2023 19:29:21 GMT

It looks to me like nrfx_gpiote_input_configure is called by the LPUART driver. In NCS v2.3.0 I see it called in the functions req_pin_init and rdy_pin_init.

As for the pins being swapped I've already corrected that but it doesn't affect the behavior.

If I have the GPIOTE interrupt cell in the DTS but generate no GPIO interrupts the fatal error does not occur. The fatal error occurs when:

a GPIO configured as an interrupt input,
the interrupts line for GPIOTE in the DTS, and
that GPIO line triggers the interrupt.

Unfortunately the board does not have 4 non-QSPI pins wired to the nRF9160. The pins I listed previously are the only ones connected between the two chips. I have tried with the REQ and RDY pins being non-QSPI pins, and with QSPI disabled in the DTS and neither changed the behavior.

Changing the prj.conf to include CONFIG_NRFX_GPIOTE_NUM_OF_EVT_HANDLERS=10 didn't change the behavior.

In case the GPIOTE IRQ wasn't being connected I tried adding this line to my code:

    IRQ_CONNECT(DT_IRQN(DT_NODELABEL(gpiote)),
                DT_IRQ(DT_NODELABEL(gpiote), priority),
                nrfx_isr, nrfx_gpiote_irq_handler, 0);

But it creates this build error:

gen_isr_tables.py: error: multiple registrations at table_index 13 for irq 13 (0xd)
Existing handler 0x1e063, new handler 0x1e063
Has IRQ_CONNECT or IRQ_DIRECT_CONNECT accidentally been invoked on the same irq multiple times?

It also looks like nrfx_gpiote_irq_handler isn't being called. If I add a function call to set an LED in this routine it doesn't turn on.

RE: LPUART nRF5340 fatal error

Øivind — Fri, 12 May 2023 17:17:14 GMT

I started looking into the gpiote after your latest update, apologies for not posting a response.
How are you setting up your gpiote handlers? Could I see the code where you call nrfx_gpiote_input_configure etc.? Do you get the error if you keep the interrupts line, but never call any gpiote functions?

Could you try changing the RX and TX pins to pins which are not by default qspi pins as well?
And I assume that the pins being swapped in default vs sleep is not intentional?
How many gpiote callbacks are you setting up? There is a config you should adjust if you require more than 2 handlers:

CONFIG_NRFX_GPIOTE_NUM_OF_EVT_HANDLERS=2

RE: LPUART nRF5340 fatal error

Chris Burns — Tue, 09 May 2023 23:18:29 GMT

Additional info: any GPIO interrupts, even if they're not related to LPUART, cause the "Unhandled interrupt" error if I have the interrupts line in gpiote in the DTS file:

&gpiote {
status = "okay";
interrupts = <13 NRF_DEFAULT_IRQ_PRIORITY>;
};

If I remove (or comment out) the interrupts line above then GPIO interrupts work normally.

RE: LPUART nRF5340 fatal error

Chris Burns — Thu, 04 May 2023 17:10:21 GMT

This is on a custom board with custom board files. I created the DTS files for both the board with the nRF52840 and the board with the nRF5340.

The pins wired between the two microcontrollers (on the nRF5340 side) are:

0.13, 0.14, 0.15, 0.16, 0.17, 0.18, 0.19, 0.20, 0.21

After your comment I checked the product spec and noticed several of these pins are dedicated QSPI pins, so I changed the DTS to set the QSPI peripheral to "disabled" (from "okay"). This didn't change the result - I still get the unhandled interrupt.

For another test I changed the REQ and RDY pins to be some of the ones that aren't connected to QSPI. The result is the same - ZEPHYR FATAL ERROR 1: Unhandled interrupt on CPU 0.

Again, for both of these tests the error occurs when the nRF9160 attempts to send something and it looks to be tied to the REQ pin on the nRF5340 going high.

Here are the relevant sections from the DTS file:

&gpiote {
status = "okay";
interrupts = <13 NRF_DEFAULT_IRQ_PRIORITY>;
};

&uart1 {
    status = "okay";
    current-speed = <460800>;
    pinctrl-0 = <&lpuart_uart1_default>;
    pinctrl-1 = <&lpuart_uart1_sleep>;
    pinctrl-names = "default", "sleep";

    lpuart: nrf-sw-lpuart {
        compatible = "nordic,nrf-sw-lpuart";
        status = "okay";
        req-pin = <14>;
        rdy-pin = <16>;
    };
};

And in the pinctrl DTSI file:

lpuart_uart1_default: lpuart_uart1_default {
    group1 {
        psels = <NRF_PSEL(UART_TX, 0, 13)>,
                    <NRF_PSEL(UART_RX, 0, 15)>;
    };
};

lpuart_uart1_sleep: lpuart_uart1_sleep {
    group1 {
        psels = <NRF_PSEL(UART_RX, 0, 13)>,
                    <NRF_PSEL(UART_TX, 0, 15)>;
        low-power-enable;
    };
};

RE: LPUART nRF5340 fatal error

Øivind — Thu, 04 May 2023 10:46:17 GMT

Hi,

Are you using custom boards for these tests, or are you currently testing with DKs?
Are you using the DK board files found in the SDK, or custom board files?
Which pins on the nRF5340 are you using for LPUART?
Could I see any overlay files or other changes to the devicetree you have made?

My first thought is that the difference between the nRF52840 and the nRF5340 is the default setup for the pin.
Some pins may require an extra step to be changed from their default configuration.