unknow data when use qspi panel

RE: unknow data when use qspi panel

Kazi Afroza Sultana — Wed, 14 May 2025 17:14:03 GMT

Hello wayne,

The QSPI is created mainly to work with flash devices, and it follows a certain instruction set. If the LCD does not implement the same instruction set, you need to use regular (high-speed) SPI.

You need to check the datasheet of the LCD to see what it supports. If it does not support the same instruction set (I think this is JEDEC), SPIM would be a better option. There is some support for custom instructions, but this would likely be slower than using high-speed SPIM in HW.

RE: unknow data when use qspi panel

Wayne_Chang — Wed, 30 Apr 2025 04:14:52 GMT

Hi Kazi,

I have previously used SPI to drive an LCD. I only began testing QSPI in order to increase the framerate. If the QSPI on the nRF52840 does not support functionalities beyond flash memory, I am considering switching to a different MCU.

However, I need a clear and definitive answer:
Is it possible to use the QSPI interface on the nRF52840 to drive an LCD?

BR,
Wayne

RE: unknow data when use qspi panel

Kazi Afroza Sultana — Tue, 29 Apr 2025 14:02:23 GMT

Hello Wayne,

You may try to use SPI for your LCD panel instead of QSPI?

RE: unknow data when use qspi panel

Wayne_Chang — Fri, 11 Apr 2025 07:46:15 GMT

Hi Kazi,

i only used nrf52840-dk to make sure that there is no other factors interfere.

this is my device tree about qspi

&qspi {
    status = "okay";
    pinctrl-0 = <&qspi_default>;
    pinctrl-1 = <&qspi_sleep>;
    pinctrl-names = "default", "sleep";
};

&qspi_default {
        group1 {
                psels = <NRF_PSEL(QSPI_SCK, 0, 16)>,
                        <NRF_PSEL(QSPI_IO0, 0, 25)>, // SDA
                        <NRF_PSEL(QSPI_IO1, 0, 13)>,
                        <NRF_PSEL(QSPI_IO2, 0, 15)>,
                        <NRF_PSEL(QSPI_IO3, 0, 24)>,
                        <NRF_PSEL(QSPI_CSN, 1, 4)>;
        };
};

&qspi_sleep {
        group1 {
                psels = <NRF_PSEL(QSPI_SCK, 0, 16)>,
                        <NRF_PSEL(QSPI_IO0, 0, 25)>, // SDA
                        <NRF_PSEL(QSPI_IO1, 0, 13)>,
                        <NRF_PSEL(QSPI_IO2, 0, 15)>,
                        <NRF_PSEL(QSPI_IO3, 0, 24)>;
                low-power-enable;
        };
        group2 {
                psels = <NRF_PSEL(QSPI_CSN, 1, 4)>;
                low-power-enable;
                bias-pull-up;
        };
};

and this is what function i tried

void qspi_write(const uint8_t *data, size_t len)
{
	int err = nrfx_qspi_write(data, len, 0);
	if (err != NRFX_SUCCESS)
	{
		// printk("QSPI write failed: %d\n", err);
		return;
	}
	// printk("QSPI wrote %d bytes\n", len);
}

void qspi_raw_send(const uint8_t *data, size_t len)
{

    NRF_QSPI->WRITE.DST = 0; 
    NRF_QSPI->WRITE.SRC = (uint32_t)data;
    NRF_QSPI->WRITE.CNT = len;

    NRF_QSPI->EVENTS_READY = 0;

    NRF_QSPI->TASKS_WRITESTART = 1;

    while (!NRF_QSPI->EVENTS_READY) {}
    NRF_QSPI->EVENTS_READY = 0;

	// printf("Sent %d bytes\n", len);
}

I also tried

&mx25r64 {
status = "disabled";
};

but it also get the same result

Wayne

RE: unknow data when use qspi panel

Kazi Afroza Sultana — Thu, 03 Apr 2025 11:58:16 GMT

Hello Wayne,

How have you set the QSPI in the application? Can I see the board file ( dts, pincontrol, overlay) of your application? Any external flash chip is set under QSPI node? If it is then you need to disbale the default flash chip and properly configure the new on in device tree overlay file.

&mx25r64 {
    status = "disabled";
};

Do you have HFXO on your board?

Also, there is a known errata [244] QSPI: External flash and QSPI returns erroneous data when the SoftDevice is running about this erroneous data while using QSPU for nRF5SDK.

The workaround says ''Ensure that the clock source is not switched during the QSPI operations. For example, force the HFXO enabled when SoftDevice is used by calling sd_clock_hfclk_request() after sd_softdevice_enable() during QSPI operations''

I think same workaround can be applicable using MPSL clock module for NCS. The MPSL clock module API enables the application to safely request and release the HFXO while the protocol stacks are enabled. MPSL can continue to use the HFXO after it is released if it is requested by protocol stacks. HFXO is stopped when it is no longer needed.

mpsl_clock_hfclk_request();
// Perform QSPI operations
mpsl_clock_hfclk_release();

for direct register access can use following code before starting the QSPI operation

NRF_CLOCK->TASKS_HFCLKSTART = 1;
while (NRF_CLOCK->EVENTS_HFCLKSTARTED == 0);
NRF_CLOCK->EVENTS_HFCLKSTARTED = 0;

// Perform QSPI operations

You can try all these probable solutions and also can send me the board file, so, in the meantime I can check if something wrong with the configuration of QSPI node.

Thanks.

Kazi