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