unknow data when use qspi panel

[Wayne_Chang]

Hi all,

I applied QSPI driver on NCS 2.4.0  with QSPI LCD panel and I encountered the problem.

The red area is the data I sent, but the blue area is not what I sent.

I already try many way to send with qspi, like nrfx_qspi_write() or directly write to register NRF_QSPI

but all result are the same.

Is this caused by the hardware design, or can I modify it on the software side?

I already read the post below, but it seems no solution update.

 RE: NRF52840 QSPI Driver LCD（LCD Driver IC GC9C01） 

Wayne

[Kazi Afroza Sultana]

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.

BR

Kazi

[Wayne_Chang]

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

[Kazi Afroza Sultana]

Hello Wayne,

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

[Wayne_Chang]

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

[Kazi Afroza Sultana]

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.