You maybe right. Call to cyw43_arch_gpio_put() haging (or just taking very long time) could be just a side effect of already crashed/hung radio module (especially since toggling the LED 10x faster doesn't trigger the issue any faster). I'll test without touching the GPIO pin on cyw43 at all...This has been an issue for me forever. I hope you will find a resolution as despite hundreds of hours of testing and debugging I have not found a cause or solution. I've posted about hangs in cyw43 activity previously but no help has been forthcoming. I'm not convinced that that cyw43_arch_gpio_put is actually the issue as disabling that functionality has not stopped the hangs. It seems that any cyw43 activity can cause the problem but I can't tie it down so the do_Ioctl timeout may be a symptom rather than the underlying cause.
It sure looks like there could be buggy firmware on this radio module and some packets received over radio can trigger unit to "crash"... (wouldn't be first radio module with buggy firmware
)Radio module crashing/rebooting probably could explain "corrupt" (?) SPI transfer that seemed to trigger the problem:
Code:
WLAN: changed flow control: 0 -> 255WLAN: changed flow control: 255 -> 0SPI invalid bytes pending 1820[CYW43] error: hdr mismatch 6291 ^ ba56[CYW43] do_ioctl(2, 263, 16): timeout[CYW43] do_ioctl(2, 263, 16): timeoutDoes the new SDK include updated firmware?After all sorts of mitigation strategies, I now see hangs after days rather than hours but they still happen. SDK2.0.0 seems to be an improvement but not a solution.
One in 1.5.1 seems quite old:
Code:
Version: 7.95.49 (2271bb6 CY) CRC: b7a28ef3 Date: Mon 2021-11-29 22:50:27 PST Ucode Ver: 1043.2162 FWID 01-c51d9400Statistics: Posted by vadelma-pi — Fri Aug 30, 2024 11:26 pm