ST7735 SPI transfer timed out

[Saketeas]

The sdk I'm using is https://github.com/hanwckf/immortalwrt-mt798x

Compiled device tree is mt7981-spim-nor-rfb.dts

I followed this tutorial : https://community.milkv.io/t/spi-milk-v-duo-st7735/625

The following error occurred after the system started: [ 2.358179] fb_st7735r spi0.0: fbtft_update_display(start_line=0, end_line=127) [ 2.365482] fb_st7735r spi0.0: fbtft_write_reg8_bus8: 2a 00 00 00 9f [ 2.371830] fb_st7735r spi0.0: fbtft_write_spi(len=1): 2a [ 2.377245] fb_st7735r spi0.0: fbtft_write_spi(len=4): 00 00 00 9f [ 2.383437] fb_st7735r spi0.0: fbtft_write_reg8_bus8: 2b 00 00 00 7f [ 2.389788] fb_st7735r spi0.0: fbtft_write_spi(len=1): 2b [ 2.395202] fb_st7735r spi0.0: fbtft_write_spi(len=4): 00 00 00 7f [ 2.401395] fb_st7735r spi0.0: fbtft_write_reg8_bus8: 2c [ 2.406706] fb_st7735r spi0.0: fbtft_write_spi(len=1): 2c [ 2.412118] fb_st7735r spi0.0: fbtft_write_vmem16_bus8(offset=0, len=40960) [ 2.419091] fb_st7735r spi0.0: fbtft_write_spi(len=4096): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... [ 2.637445] fb_st7735r spi0.0: SPI transfer timed out [ 2.642497] spi_master spi0: failed to transfer one message from queue [ 2.649016] fb_st7735r spi0.0: fbtft_update_display: write_vmem failed to update display buffer [ 2.657703] fb_st7735r spi0.0: Display update: 132 kB/s, fps=0 [ 2.663528] fb_st7735r spi0.0: fbtft_write_reg8_bus8: e0 0f 1a 0f 18 2f 28 20 22 1f 1b 23 37 00 07 02 10 [ 2.672999] fb_st7735r spi0.0: fbtft_write_spi(len=1): e0 [ 2.678415] fb_st7735r spi0.0: fbtft_write_spi(len=16): 0f 1a 0f 18 2f 28 20 22 1f 1b 23 37 00 07 02 10 [ 2.687822] fb_st7735r spi0.0: fbtft_write_reg8_bus8: e1 0f 1b 0f 17 33 2c 29 2e 30 30 39 3f 00 07 03 10 [ 2.697295] fb_st7735r spi0.0: fbtft_write_spi(len=1): e1 [ 2.702711] fb_st7735r spi0.0: fbtft_write_spi(len=16): 0f 1b 0f 17 33 2c 29 2e 30 30 39 3f 00 07 03 10 [ 2.712223] graphics fb0: fb_st7735r frame buffer, 160x128, 40 KiB video memory, 4 KiB buffer memory, fps=31, spi0.0 at 32 MHz

There is fb0 in /dev, but cat /dev/urandom > /dev/fb0 gives an error: [ 292.743566] fb_st7735r spi0.0: fbtft_update_display(start_line=0, end_line=127) [ 292.750883] fb_st7735r spi0.0: fbtft_write_reg8_bus8: 2a 00 00 00 9f [ 292.757246] fb_st7735r spi0.0: fbtft_write_spi(len=1): 2a [ 292.762828] fb_st7735r spi0.0: fbtft_write_spi(len=4): 00 00 00 9f [ 292.769054] fb_st7735r spi0.0: fbtft_write_reg8_bus8: 2b 00 00 00 7f [ 292.775409] fb_st7735r spi0.0: fbtft_write_spi(len=1): 2b [ 292.780825] fb_st7735r spi0.0: fbtft_write_spi(len=4): 00 00 00 7f [ 292.787020] fb_st7735r spi0.0: fbtft_write_reg8_bus8: 2c [ 292.792334] fb_st7735r spi0.0: fbtft_write_spi(len=1): 2c [ 292.797745] fb_st7735r spi0.0: fbtft_write_vmem16_bus8(offset=0, len=40960) [ 292.804720] fb_st7735r spi0.0: fbtft_write_spi(len=4096): f0 6c 36 8e 04 19 88 1a 7e 54 ca 81 f6 42 ca c9 f3 c9 6b d6 fc 6d e8 d9 33 0d e9 88 7e fc 5d 40 ... [ 293.023525] fb_st7735r spi0.0: SPI transfer timed out [ 293.028591] spi_master spi0: failed to transfer one message from queue [ 293.035121] fb_st7735r spi0.0: fbtft_update_display: write_vmem failed to update display buffer [ 293.043814] fb_st7735r spi0.0: Display update: 132 kB/s, fps=0

st7735 can drive normally in other development boards,the spi loop communication is also normal

So can you help me? Thank you all

[Saketeas]

Today I tried to use Orangepi3lts and my faulty development board driver information The problematic development board：https://www.alibaba.com/product-detail/MT7981BA-mt7976C-mt7531AE-MT7981B-2-4g_1600870622783.html?spm=a2700.shop_plgr.41413.5.677f5c08H0gi9R

orangepi3lts：kernel5.10

The problematic development board：kernel5.4

[notro]

This looks like a problem with the SPI controller driver. The "timed out" error comes from spi_transfer_wait() and is cause by the controller driver not calling spi_finalize_current_transfer(). I'm not familiar with that board so I can't help you with that problem I'm afraid.

The default tx buffer size is 4KiB, you could try and lower that to see if it chokes on "large" transfers. The txbuflen DT property controls the buffer size (ref). Use power of two values to be sure it doesn't cause any problems.

[Saketeas]

Thank you for your reply and suggestions. I tried txbuflen using the following values:3072,2048,1024,512,not solving the problem.

This is the spi definition for part of my devicetree:

&spi1 {
    pinctrl-names = "default";
    pinctrl-0 = <&spic_pins>;
    status = "okay";

    spi_st7735@0 {
        compatible = "sitronix,st7735r";
        reg = <0>;
        debug = <7>;
        dc-gpios=<&pio 4 GPIO_ACTIVE_HIGH>; 
        reset-gpios=<&pio 5 GPIO_ACTIVE_HIGH>;
        spi-max-frequency = <10000000>;
        txbuflen = <512>;
        rotation = <270>;
        buswidth = <8>;
        };  

};
&pio {
    spic_pins: spi1-pins {
        mux {
            function = "spi";
            groups = "spi1_1";
        };
    };
    spi2_flash_pins: spi2-pins {
        mux {
            function = "spi";
            groups = "spi2", "spi2_wp_hold";
        };

        conf-pu {
            pins = "SPI2_CS", "SPI2_HOLD", "SPI2_WP";
            drive-strength = <MTK_DRIVE_8mA>;
            bias-pull-up = <MTK_PUPD_SET_R1R0_11>;
        };

        conf-pd {
            pins = "SPI2_CLK", "SPI2_MOSI", "SPI2_MISO";
            drive-strength = <MTK_DRIVE_8mA>;
            bias-pull-down = <MTK_PUPD_SET_R1R0_11>;
        };
    };
};

dtsi

spi1: spi@1100b000 {
        compatible = "mediatek,ipm-spi-single";
        reg = <0 0x1100b000 0 0x100>;
        interrupts = <GIC_SPI 141 IRQ_TYPE_LEVEL_HIGH>;
        clocks = <&topckgen CK_TOP_CB_M_D2>,
             <&topckgen CK_TOP_SPIM_MST_SEL>,
             <&infracfg_ao CK_INFRA_SPI1_CK>,
             <&infracfg_ao CK_INFRA_SPI1_HCK_CK>;
        clock-names = "parent-clk", "sel-clk", "spi-clk", "spi-hclk";
        status = "disabled";
    };

If you have any debugging suggestions, please reply,I've been working on it for a month

Thank you all

[notro]

I have one more suggestion, "mediatek,ipm-spi-single" points to drivers/spi/spi-mt65xx.c being used as the SPI controller driver. That driver uses DMA for transfers longer than MTK_SPI_MAX_FIFO_SIZE which is 32 bytes. You could try setting txbuflen=32. This will trigger a different code path in the controller driver which might work if DMA is the problem.

[Saketeas]

Thank you very much for your advice. Although the contents of my spi-mt65xx.c are slightly different from the official ones, txbuflen=32 does solve the spi timeout problem.

[Saketeas]

I'm sorry, I'm too much of a beginner，I have another problem After executing the command cat /dev/urandom > /dev/fb0, the error message is "cat: write error: No space left on device", and then ST7735 is still a white screen. I followed this tutorial later :https://www.jianshu.com/p/d256b3ccb42a It was not possible to check the inode status on my system，see help is no -i argument

Filesystem                Size      Used Available Use% Mounted on
/dev/root                13.5M     13.5M         0 100% /rom
tmpfs                   112.3M    316.0K    112.0M   0% /tmp
/dev/mtdblock7           12.1M      1.1M     11.0M   9% /overlay
overlayfs:/overlay       12.1M      1.1M     11.0M   9% /
tmpfs                   512.0K    512.0K         0 100% /dev

However, I saw on the forum that it is normal for /dev/root to be full, so I was confused https://www.right.com.cn/FORUM/forum.php?mod=viewthread&tid=493960

"lsof | grep deleted" There is no output after the execution, so I understand it has nothing to do with this

I'm sorry to bother you with these questions

[notro]

I have another problem After executing the command cat /dev/urandom > /dev/fb0, the error message is "cat: write error: No space left on device"

That's normal, urandom produces more data than fb0 has room for, the framebuffer is filled up.

and then ST7735 is still a white screen.

White screen means the controller has not been configured properly.

[Saketeas]

Thank you for reminding me. I remembered that I recompiled once, which resulted in my changes to fb driver disappeared and gpio did not get control. The modification has been successful according to the tutorial.