--- title: "W6100-EVB-Pico2 Interrupt Stalling with io6Library" url: "https://maker.wiznet.io/forum/15739" markdown_url: "https://maker.wiznet.io/forum/15739/md" type: "Forum topic" category: "Ethernet Chips" author: "cameronbprince" created: "2025-05-28T05:07:05+09:00" last_activity: "2025-05-29T16:56:53+09:00" language: "en" views: 7 replies: 3 source: "WIZnet Makers forum (https://maker.wiznet.io/forum/)" --- # W6100-EVB-Pico2 Interrupt Stalling with io6Library ## Question Asked by cameronbprince on 2025-05-28 in Ethernet Chips. 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: 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 to be an io6Library or configuration issue. Attachments: - w6100_interrupt_test.c - serial_log_20250526.txt - CMakeLists.txt - test_packets.py Could you please advise on resolving interrupt stalling and overflow? Thank you. Best regards, Cameron ## Replies ### Reply 1 by Hannah, 2025-05-28 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? 1. What is the interrupt trigger type being used? 2. Check the actual interrupt register values:  - `SIR` (SOCKET Interrupt Register)  - `Sn_IR` (SOCKET n Interrupt Register) 3. Verify the interrupt waveform. ### Reply 2 by cameronbprince, 2025-05-29 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. Session attached (Session6.sal). Notes: 95 packets/s (49 bytes) is within W6100’s 8KB capacity (~143 packets). Polling (e.g., w6x00_loopback.c) handles this rate, indicating an io6Library or INTn issue. SIMR=0x00 post-reinitialization (twice) disables interrupts, likely a reinitialize_socket bug. Questions: Why is Int1 triggered with SIR=0x00, INTn=1? Is this an io6Library (commit a3f5a6) bug? Why is SIMR=0x00 post-reinitialization, disabling interrupts? Why no Sn_IR_RECV initially at RX_RSR=6156? Are INTn settings (e.g., pull-up, SPI) incorrect? What explains low waveform edge frequency (~2.6/s vs. 95/s) and noise pulses? Please advise on resolving stalling, especially SIMR=0x00. I can provide more logs or tests. Thank you. Cameron Attachments: w6100_interrupt_test.c serial_log_20250528.txt digital.csv Session6.sal P.S. After typing this up, I don't see a way to attach files anymore. How can I get these to you? ### Reply 3 by Hannah, 2025-05-29 (in reply to reply 2) Please resend all the attached files to the email address below. I’ll review them and get back to you with a response. hannah@wiznet.io 1. you mentioned that you used the `io6Library` (commit `a3f5a6`). Could you please share the link? 2. What is the process post-reinitialization? --- Source: https://maker.wiznet.io/forum/15739