Closed peterharperuk closed 1 year ago
Its 100 udp packets per second that seems to cause the problem - still not unreasonable? I can reproduce it in the Infineon example code so will report it to them now.
100 packets/sec seems still very 'slow' rate, would expect it to be able to handle much more.... (I ran some quick tests with RPi Zero and it easily transmitted around 5000 packets/second with small UDP packets...)
I've been trying to reproduce this issue but cannot. I didn't get to building the picow_udp_beacon.c
because it seems I need to downgrade GCC to below version 11.3. Instead I tried to reproduce in MicroPython, but without any luck:
iperf3.client('192.168.0.xx', udp=True, bandwidth=10*1024*1024)
doesn't show any errors.s.sendto(bytearray(128), ('192.168.0.xx', 4444))
(in an attempt to mimic picow_udp_beacon.c
) also doesn't show any errors (with no delay, and a 10ms delay in the loop).I can try to get picow_udp_beacon.c
building and running next.
Update: I can reproduce the problem using picow_udp_beacon.c
, in both polling and background mode. I get the error even with a 50ms delay between sending UDP packets.
Update: I can now reproduce with MicroPython (with debug prints enabled!, it seems they aren't enabled by default) and the following script:
import time
import socket
s=socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
while True:
print('send')
s.sendto(bytearray(128), ('192.168.0.xx', 4444))
time.sleep(0.080)
80ms between loops seems to be the limit at which it starts to happen.
There also seems to be a semi-regular pattern where the error is printed every 13 UDP packets.
It'll happen more regularly the more data you send. I've reproduced it with TCP using iperf using two interfaces if you receive on one and send on the other - bit weird.
@dpgeorge I should point out that the driver is not at fault here - I can reproduce this problem with Infineon's code base.
I can reproduce this problem with Infineon's code base.
Yes I saw your earlier comment about that.
I cannot reproduce the problem with the Murata 1DX and the w4343WA1_7_45_98_50_combined.h
firmware. So it's specific to the SPI interface and/or the w43439A0_7_95_49_00_combined.h
firmware.
This spurious packet is always 240 bytes long and is being detected as an async event (as opposed to control or data packet). I suspect it could be debugging and/or profiling information sent back from the WiFi processor. In that case it's probably safe to ignore (and the original WICED WWD driver does ignore such packets, albeit after printing a debug message).
I just happen to notice that with SDK 1.5.0, I seem to only get these errors with "Release" builds:
[CYW43] got unexpected packet -9
While "Debug" builds I don't seem to see these. That seems odd?
I can see it in debug. I suspect you were just "unlucky".
Later: The problem goes away for me if I enabled stdio usb. I do wonder if we're provoking the problem - maybe by making too many requests or something.
If you send udp messages quickly (e.g. one every 10ms or less), you see a lot of these messages.
[CYW43] got unexpected packet -9
See https://github.com/georgerobotics/cyw43-driver/issues/33 for the original reporter and the attached modification to https://github.com/raspberrypi/pico-examples/pull/275, which also repros the problem.
0 cyw43_ll_process_packets (self_in=self_in@entry=0x20000fa0)
1 0x1000382e in cyw43_poll_func () at /home/peterh/source/pico/pico-sdk/lib/cyw43-driver/src/cyw43_ctrl.c:236
2 0x1000087c in low_priority_irq_handler ()
3
4 to_us_since_boot (t=...) at /home/peterh/source/pico/pico-sdk/src/common/pico_base/include/pico/types.h:48
5 time_reached (t=...) at /home/peterh/source/pico/pico-sdk/src/rp2_common/hardware_timer/include/hardware/timer.h:115
6 sleep_until (t=...) at /home/peterh/source/pico/pico-sdk/src/common/pico_time/time.c:361
7 0x10005214 in sleep_us (us=) at /home/peterh/source/pico/pico-sdk/src/common/pico_time/include/pico/time.h:102
8 0x1000524e in sleep_ms (ms=ms@entry=100) at /home/peterh/source/pico/pico-sdk/src/common/pico_time/time.c:393
9 0x1000038a in run_udp_beacon () at /home/peterh/source/pico/pico-examples/pico_w/udp_beacon/picow_udp_beacon.c:55
10 0x10000434 in main () at /home/peterh/source/pico/pico-examples/pico_w/udp_beacon/picow_udp_beacon.c:77
The -9 error comes from here...
0 sdpcm_process_rx_packet (self=self@entry=0x20000fa0, buf=buf@entry=0x20000fbc <cyw43_state+28> "",
1 0x10002486 in cyw43_ll_sdpcm_poll_device (self=self@entry=0x20000fa0, len=len@entry=0x20041f40,
2 0x10002532 in cyw43_ll_process_packets (self_in=self_in@entry=0x20000fa0)
3 0x1000382a in cyw43_poll_func () at /home/peterh/source/pico/pico-sdk/lib/cyw43-driver/src/cyw43_ctrl.c:236
4 0x1000087c in low_priority_irq_handler ()
5
6 to_us_since_boot (t=...) at /home/peterh/source/pico/pico-sdk/src/common/pico_base/include/pico/types.h:48
7 time_reached (t=...) at /home/peterh/source/pico/pico-sdk/src/rp2_common/hardware_timer/include/hardware/timer.h:115
8 sleep_until (t=...) at /home/peterh/source/pico/pico-sdk/src/common/pico_time/time.c:361
9 0x10005210 in sleep_us (us=) at /home/peterh/source/pico/pico-sdk/src/common/pico_time/include/pico/time.h:102
10 0x1000524a in sleep_ms (ms=ms@entry=10) at /home/peterh/source/pico/pico-sdk/src/common/pico_time/time.c:393
11 0x1000038a in run_udp_beacon () at /home/peterh/source/pico/pico-examples/pico_w/udp_beacon/picow_udp_beacon.c:55
12 0x10000434 in main () at /home/peterh/source/pico/pico-examples/pico_w/udp_beacon/picow_udp_beacon.c:77
So it seems to be mostly blank where it shouldn't be. It doesn't look like an ethernet packet. They don't do any harm as they're ignored but they must waste time. I think we'll have to reproduce this and ask Infineon. I think we should be able to send 10 UDP packets a second?!
0001-Modify-beacon-example-to-reproduce-unexpected-packet.patch.gz