Execution hangs on `sleep_us(1)` on Pico W

[cshaa]

On my Raspberry Pi Pico W using the latest SDK, trying to use the library leads to crashing the CPU – execution just hangs, and the chip doesn't do anything else. Here's my project that reproduces the bug: pico-st7789-bug. (This is happening regardless of whether there's any display connected to the Pico.)

I found out that it's caused by the sleep_us(1) calls at various places in the code (lines: 28, 33, 38, 40, 45, 50, 159, 164, 170, 175). It seems that there is a race condition in the SDK that leads to missing the interrupt for the short timer and hanging indefinitely – potentially only on Pico W devices. Related issues: https://github.com/raspberrypi/pico-sdk/issues/1552, https://github.com/raspberrypi/pico-sdk/issues/1500, https://github.com/micropython/micropython/issues/12873

If I remove all these sleep_us calls, the library starts working as expected, and I'm able to run the blink example on a 240x240 display. If there isn't sufficient rationale for the sleep_us(1) calls, I advise to remove them altogether – at least for me the library works perfectly without them. However, if they are necessary for correct timing, we can replace them with something like busy_wait_at_least_cycles, and if they're a walkaround for spi_write_blocking not blocking enough, they can be replaced with a busywait until SPI is done:

while (((spi_hw_t *)st7789_cfg.spi)->sr & SPI_SSPSR_BSY_BITS)
{
  tight_loop_contents();
}

I can make a PR with any of the proposed solutions.

[TheCustomFHD]

I will cross-test this with my screen aswell during the weekend, would be interesting if this works for me too.

[TheCustomFHD]

Soo.. it wasnt exactly uh.. "that weekend", sorry for that. BUT! i can confirm, that with a sleep_us(10), my display functions. It also functions without the sleep_us(1)or sleep_us(10) waits. This is very nice for me, and huge thanks to @m93a for figuring this out. Now my old Rapsberry Pi 1 A Screens have a new nice usecase as a screen for my Pico's, amazing!

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[cshaa]

@stale As far as I know, this is still an issue.

[TheCustomFHD]

I can confirm, this is still broken. Waiting for a response from what the Repository Owner wants to do

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[cshaa]

Issues usually don't get fixed by ignoring them.

[TheCustomFHD]

Indeed, this fix is essentially free (it takes less than 3 minutes to implement). Although this library is painfully slow anyway. Iirc, the screen/driver supports to dump the whole framebuffer into it at once, which would be lots faster (but consume more RAM ofc)