We have a custom board with an nRF5340 connected to a W5500 ethernet interface. The interrupt handler for the W5500 is never executed, despite the interrupt signal being asserted.
The setup
NCS 2.6.0, custom board definition based on app_ns.
The pinout is the following:
|
INT |
P1.02 |
|
RST |
P0.03 |
|
SPI CS |
P0.02 |
|
SPI CLK |
P0.09 |
|
SPI MISO |
P0.13 |
|
SPI MOSI |
P0.16 |
This is the relevant part of the dts for our custom board:
&pinctrl {
spi4_default: spi4_default {
group1 {
psels = <NRF_PSEL(SPIM_SCK, 0, 9)>,
<NRF_PSEL(SPIM_MISO, 0, 13)>,
<NRF_PSEL(SPIM_MOSI, 0, 16)>;
nordic,drive-mode = <NRF_DRIVE_E0E1>;
};
};
spi4_sleep: spi4_sleep {
group1 {
psels = <NRF_PSEL(SPIM_SCK, 0, 9)>,
<NRF_PSEL(SPIM_MISO, 0, 13)>,
<NRF_PSEL(SPIM_MOSI, 0, 16)>;
low-power-enable;
};
};
};
&spi4 {
status = "okay";
cs-gpios = <&gpio0 2 GPIO_ACTIVE_LOW>;
pinctrl-0 = <&spi4_default>;
pinctrl-1 = <&spi4_sleep>;
pinctrl-names = "default", "sleep";
w5500: w5500@0 {
compatible = "wiznet,w5500";
reg = <0>;
zephyr,random-mac-address;
spi-max-frequency = <DT_FREQ_M(32)>;
int-gpios = <&gpio1 2 GPIO_ACTIVE_LOW>;
reset-gpios = <&gpio0 3 GPIO_ACTIVE_LOW>;
};
};
What we have tried/verified
We have verified the signal integrity on the nRF side and it looks ok.
We have verified the full interface at the nRF side with a logic analyser, and it looks ok except for the fact that once the INT signal is asserted (around the 4950.68ms mark in the screenshot below), it never gets deasserted again (the interrupt is not serviced)
We have tried moving the INT signal from P1.02 to a pin on the gpio0 block (in case there was something funny about the gpio1 block), with no effect.
We have used the debugger, and established the following:
- the w5500 driver init (zephyr/drivers/ethernet/eth_w5500.c::w5500_init) succeeds, and receives no error when initing the SPI, the INT GPIO and its interrupt.
- the w5500 interrupt callback (zephyr/drivers/ethernet/eth_w5500.c::w5500_gpio_callback) is never executed, even when the INT signal is asserted
- the GPIOTE config seems correct: GPIOTE1_NS has INTENSET=0x80000080 and CONFIG[7]=0x00022201
- more importantly, not even the nrfx_gpiote.c::irq_handler() is executed
- also importantly, GPIO P1_NS->IN reads 0x00000004 (i.e P1.02 is high) even when the pin is measured low:
I have a hard time making sense of the latest point (P1.02 being read high when we are measuring it low), as I don't see how that could happen.
Am I missing something obvious here? In the nRF5340 have stumbled before into issues with secure/non-secure domain, pins being routed to different cores etc, but this seems pretty basic.
