W6100-EVB-Pico2 Interrupt Stalling with io6Library

Question

Hello, I'm facing an issue with interrupt-driven UDP packet reception on the W6100-EVB-Pico2 (RP2350) using io6Library (commit a3f5a6). Interrupts work for three packets but then stall, causing buffer overflow and forcing reliance on polling. Below is a summary of the problem and discrepancies with documentation. The docs I have found are: https://docs.wiznet.io/img/products/w6100/w6100_ds_v105e.pdf http://www.hschip.com/Private/Files/20190304152520622%E2%88%AEW6100_an_interrupt_v100e.pdf The only real example I can find is the loopback here, but it appears to use polling instead of interrupt. Setup: - Hardware: W6100-EVB-Pico2, SPI (CS: GPIO17, SCLK: GPIO18, MOSI: GPIO19, MISO: GPIO16), INTn (GPIO21, pull-up). - Software: io6Library (commit a3f5a6), Pico SDK, test program (w6100_interrupt_test.c). - Configuration: UDP socket (port 5000, DIPR=192.168.137.255, Sn_MR_UDP | Sn_MR_MULTI, SF_IO_NONBLOCK | SF_MULTI_ENABLE), IP=192.168.137.14. - Traffic: ~50 packets/s (49 bytes) from 192.168.137.10:49152 and test packets from 192.168.137.100. Observed Behavior (Serial Log, May 26, 2025): - Socket initializes: MR=0x82, SR=0x22, IMR=0x04, SIMR=0x01, DPORT=5000. - DIPR initially fails (0.0.0.0), but retry sets 192.168.137.255. - Three interrupts trigger: - Int1: t=8222639 us, SIR=0x01, Sn_IR=0x04, RX_RSR=57, INTn=0, receives from 192.168.137.100:57684, clears SIR. - Int2: t=11170235 us, receives from 192.168.137.100:64098, clears SIR. - Int3: t=18530871 us, receives from 192.168.137.10:49152, clears SIR. - Interrupts stop after Int3, RX_RSR grows to 6384 (~130 packets). - Polling processes 50 packets, reduces RX_RSR to ~3762, then reinitializes. - Post-reinitialization: RX_RSR=114, but no further interrupts, only polling. Expected Behavior (Per Documentation): - Datasheet (v1.0.5, p. 40, 66): Sn_IR_RECV (Sn_IR=0x04) should trigger for each packet, setting SIR=0x01 and INTn low. Clearing Sn_IR and SIR should allow continuous interrupts unless RX_RSR=8192. - App Note (v1.0.0, p. 4-5): Handler should process all packets (RX_RSR > 0), clear interrupts, and re-enable INTn. Issues: 1. Interrupt Stalling: Interrupts cease after three triggers despite RX_RSR=6384, SR=0x22, IMR=0x04. Expected continuous Sn_IR_RECV. 2. Buffer Overflow: RX_RSR=6384 at ~50 packets/s halts interrupts. 3. No Recovery: Post-reinitialization, no interrupts despite RX_RSR=114. 4. DIPR Failure: setSn_DIPR initially sets 0.0.0.0, requiring retry. Questions: 1. Why do interrupts stop with RX_RSR=6384? Is this an io6Library bug? 2. How to maintain interrupts at ~50 packets/s without overflow? 3. Why no interrupts post-reinitialization? Is GPIO21 or W6100 misconfigured? 4. Why does setSn_DIPR fail initially? Is a delay required? Note: The datasheet (p. 66) supports ~143 packets (57 bytes) in an 8KB buffer, handling 50 packets/s for ~2.86 seconds. W5500 tests suggest ~72,368 packets/s at 33 Mbps (Parallax Forums), and W6100 targets 25 Mbps (~54,825 packets/s). Stalling at 50 packets/s appears…

Hannah · Answer

You mentioned that interrupts have stopped, but could you clarify whether this means that the INTn pin is no longer generating interrupt signals, or if an interrupt has already occurred but hasn’t been handled yet—or perhaps is masked due to another condition? What is the interrupt trigger type being used? Check the actual interrupt register values:  - SIR (SOCKET Interrupt Register)  - Sn_IR (SOCKET n Interrupt Register) Verify the interrupt waveform.

cameronbprince · Answer

Thank you for your response. I retested with an updated w6100_interrupt_test.c (attached), adding INTn state, Sn_IMR, SIMR, and missed interrupt logging (RX_RSR>0, INTn=1). A logic analyzer captured GPIO21 (INTn) with Logic2. Below are answers based on the latest test (May 28, 2025, serial_log_20250528.txt). Interrupt Stoppage: INTn stops generating valid signals after one invalid interrupt (Int1, SIR=0x00, INTn=1). No further interrupts occur despite RX_RSR=6156 (~108 packets). The serial log shows: Int1: t=6388128 us, SIR=0x00, Sn_IR=0x00, RX_RSR=57, SR=0x22, INTn=1, logged as "Invalid SIR=0x00". Miss1: RX_RSR=57, INTn=1, followed by polling (Recv1 from 192.168.137.100:51875). Polling processes 63–151 packets/s (Recv1–691), with two overflows at RX_RSR=6156, each reducing to RX_RSR=741. Post-reinitialization (twice): RX_RSR=114, INTn=1, SIMR=0x00, no interrupts, polling continues (Miss2–271, RX_RSR=1824–6156). The handler clears Sn_IR and SIR, re-enabling INTn if SIR=0, RX_RSR=0, Sn_SR=0x22. SIMR=0x00 post-reinitialization prevents interrupts. Interrupt Trigger Type: Falling-edge trigger on GPIO21 (INTn), set via gpio_set_irq_enabled_with_callback(W6100_INT_PIN, GPIO_IRQ_EDGE_FALL, true, &w6100_interrupt_handler). Interrupt Register Values: Int1: SIR=0x00, Sn_IR=0x00, Sn_IMR=0x04, SIMR=0x01. Miss1: SIR=0x00, Sn_IR=0x00, Sn_IMR=0x04, SIMR=0x01, RX_RSR=57. Overflow: SIR=0x00, Sn_IR=0x00, Sn_IMR=0x04, SIMR=0x01, RX_RSR=6156. Post-reinitialization: SIR=0x01, Sn_IR=0x04, Sn_IMR=0x04, SIMR=0x00, RX_RSR=1824–6156 (Miss2–271). Sn_IR_RECV isn’t set initially, only post-reinitialization, but SIMR=0x00 blocks interrupts. Interrupt Waveform: Logic2 captured INTn for ~47.32s at 1 MHz (digital.csv). Early falling edges (t=1.985s, 3.334s, durations ~41ns–56µs) don’t align with Int1 (t=6.388s). From t=3.334s to t=31.940s, ~120 edges (~2.6 edges/s) occur, some in noise-like pulses (~42ns). No edges match ~95 packets/s expected. Int1’s INTn=1 and no edge suggest a false trigger…