Cyw43 read address sometimes misaligned

[Abestanis]

trafficstars

I was experiencing random crashes after 24+ hours of running a project, and the panic points to an assert in the cyw43 crate:

cyw43-0.3.0\src\bus.rs:163:9:
assertion failed: addr % 4 == 0

I've since then disabled the firmware-logs feature and not experienced that panic since.

My guess is that the initial bp_read in log_read reads some garbage which is why the second one gets a misaligned address, but I'm not too sure.

In any case though I don't think a misaligned address there is an unrecoverable error and justifies panicking. Could we either not panic and log instead or not panic and just try to read the misaligned address?

[Dirbaio]

Yes, this is caused by corruption. One possible cause is unreliable power (power the pico at 5v, not 3v3, and ensure the 5v source provides enough power (1A+). Another is going too fast, try increasing the clock divider when creating the cyw43-pio.

just try to read the misaligned address

the hardware doesn't allow this.

Could we either not panic and log instead

Maybe. Honestly this is a workaround, if things are corrupted the cyw43 driver will behave unreliably and crash later anyway, in ways that are probably harder to diagnose.

I'd recommend you try to fix the reason you're getting the corruption instead.

[Abestanis]

Thank you for the suggestions and your time.

power the pico at 5v, not 3v3, and ensure the 5v source provides enough power (1A+)

The Pi is already powered at 5V via the USB connector using a 5W USB power supply that should provide 1A.

Another is going too fast, try increasing the clock divider when creating the cyw43-pio.

I'm using the default clock settings (i.e. embassy_rp::init(Default::default());), I would assume that it should work fine with these defaults.

if things are corrupted the cyw43 driver will behave unreliably and crash later anyway, in ways that are probably harder to diagnose.

I do agree, I just find it curious that communication with the cyw43 chip seems very stable without the firmware-logs feature. So either the instability is caused by the extra communication caused by the feature, or it just surfaces more easily with it. If there are communication problems without the feature, they do not seem to have any impact so far, or they are only temporary and we could recover recover from them.

I did try to find out where this alignment requirement comes from but couldn't really find anything. In the wifi host driver reference implementation they don't seem to check for it (neither here nor in the SPI function and the pico sdk also doesn't seem to check. That of course doesn't mean that it's not an actual requirement, I'm just noting what I observed.

Since I don't need the firmware-logs feature and it works very well without it I am not to fussed about this anyways. If you don't think there is anything to change here on the cyw43 crate side, I'm happy to close the issue.

[Dirbaio]

I mean this divider https://github.com/embassy-rs/embassy/blob/38f26137fc67beb874aa73c9a7ab2150d9f3d372/examples/rp/src/bin/wifi_tcp_server.rs#L67

[Abestanis]

Ah, I misunderstood, sorry. I'm also using DEFAULT_CLOCK_DIVIDER, so I still would assume it would work without problems with this default clock divider.

[nui]

I got same issue on Raspberry pi pico 2w when using DEFAULT_CLOCK_DIVIDER.

Using RM2_CLOCK_DIVIDER work without problems.

[i509VCB]

I appear to see this issue immediately after flashing blinky_wifi with a Pico 2W. Using RM2_CLOCK_DIVIDER does fix it. Should we just set that divider by default so that the examples work (although this does slow stuff down)?

[iwanders]

I'm just chiming in with another sample point, Pico 2W without any external components, flashed over USB with picotool 2.1.1, compiled with rustc 1.88.0. To get a blinking LED I needed RM2_CLOCK_DIVIDER, as well as the task-arena-size-40960 executor feature that was mentioned here. Without that feature it stopped just before this line (at least, as identified with printing to a usb serial port).

Switching the divider sounds reasonable, with a comment that it may be possible to increase it but the example uses this for better compatibility? Perhaps that arena size feature should also be enabled such that works out of the box? Docs for that feature imply it may not be necessary on nightly, perhaps that's why some people need that and others don't?