Code size report:

   bare-arm:    +0 +0.000% minimal x86:    +0 +0.000%    unix x64:   +56 +0.007% standard[incl +32(data)]      stm32:    +0 +0.000% PYBV10     mimxrt:    +0 +0.000% TEENSY40        rp2:   +32 +0.003% RPI_PICO_W       samd:    +0 +0.000% ADAFRUIT_ITSYBITSY_M4_EXPRESS  qemu rv32:    +0 +0.000% VIRT_RV32

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 98.54%. Comparing base(4dff9cb) to head(ba92063).
Report is 6 commits behind head on master.

@@           Coverage Diff           @@##           master   #17312   +/-   ##=======================================  Coverage   98.54%   98.54%           =======================================  Files         169      169             Lines       21898    21898           =======================================  Hits        21579    21579             Misses        319      319

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report?Share it here.

Have updated the tests and run on various ports (updated in description), but have found what looks like a lower level issue on RPI_PICO_W and RPI_PICO2_W.

The newudp_recv_dontwait.py test fails when instance0 is one of these rp2 boards. The UDPrecv succeeds, then UDPsendto() appears to succeed and the frame appears to be passed into the CYW43 module ("ETHTX" is shown in the trace), but packet capture shows it is almost never sent (maybe <10% of the time it sends). Unclear why, other tests show occasional packet loss but nothing consistent like this.

The UDPrecv succeeds, then UDPsendto() appears to succeed and the frame appears to be passed into the CYW43 module ("ETHTX" is shown in the trace), but packet capture shows it is almost never sent

One interesting thing in the output withwlan.config(trace=0xFF) is that the runs which succeed are always:

1. ETHRX (first UDP packet from instance1)
2. ETHTX (UDP packet sent)
3. ETHRX (second UDP packet from instance1)

But the runs which fail always seem to be:

1. ETHRX (first UDP packet from instance1)
2. ETHRX (second UDP packet from instance1)
3. ETHTX (UDP packet "sent" but not seen in the packet capture)

Weirdly this ordering seems to be happening internal to the CYW43 module, packet captures of successful runs on the Wi-Fi AP always show the second ordering over the air (RX, RX, TX) even though the trace log shows (RX, TX, RX).