NRX QSPI Issues on 5340

[LukeC]

*EDIT* - Using NCS 2.9 

I am using the QSPI peripheral to communicate with a display.

1. I initialize the QSPI peripheral.  I have tried both blocking and non-blocking.  Both return successfully.

	//ret = nrfx_qspi_init(&config, NULL, NULL);
	ret = nrfx_qspi_init(&config, nrfx_qspi_handler, NULL);

	if (ret != NRFX_SUCCESS)
	{
		LOG_ERR("Error writing to QSPI");
	}

2.) I attempt to read or write to the QSPI peripheral. 

- I get two different errors. 

Blocking Mode - this gives me the "NRFX_TIMEOUT" error.

Non-Blocking Mode - No error

A logic analyzer shows both methods continuously transmitting data. It does not just transmit/read the specified number of bytes.

I have made sure my buffers are word aligned. 

	uint8_t read_data[16] = {0};
	ret = nrfx_qspi_read(read_data, 16, LCD_SET_REG_ADDRESS(0x81));

	if (ret != NRFX_SUCCESS)
	{
		LOG_ERR("Error reading from QSPI %s", nrfx_error_string_get(ret));
	}
	
	LOG_HEXDUMP_INF(read_data, 16, "Read data");
	
		k_sleep(K_MSEC(100));

	is_tx_done = false;
	uint32_t address = 0x80 << 8;
	uint8_t cmd[4] = {0}; //__attribute__((aligned(4)))
	cmd[0] = 0x1;
	ret = nrfx_qspi_write(cmd, sizeof(cmd), address);

	if (ret != NRFX_SUCCESS)
	{
		LOG_ERR("Error writing to QSPI, err = %s", nrfx_error_string_get(ret));
	}

3.) Overlay - I have tried disabling the QSPI or the flash for the nrf5340dk overlay.  Neither of these changes the behavior.

4.) Clock - I must call nrf_clock_hfclk192m_div_set(NRF_CLOCK, NRF_CLOCK_HFCLK_DIV_1) before reading or writing or I get an NRFX_ERROR_FORBIDDEN error.

This is due to the NRF53_ERRATA_159_ENABLE_WORKAROUND below. 

    if (qspi_errata_159_conditions_check())
    {
        return NRFX_ERROR_FORBIDDEN;
    }
    
    static bool qspi_errata_159_conditions_check(void)
{
#if NRF_CLOCK_HAS_HFCLK192M && NRF53_ERRATA_159_ENABLE_WORKAROUND
    if ((nrf_clock_hfclk192m_div_get(NRF_CLOCK) != NRF_CLOCK_HFCLK_DIV_1) ||
        (nrf_clock_hfclk_div_get(NRF_CLOCK) != NRF_CLOCK_HFCLK_DIV_2))
    {
        return true;
    }
    else
#endif
    {
        return false;
    }
}

I have tried disabling this workaround in may CMakeFile.txt with target_compile_definitions(app PRIVATE NRF53_ERRATA_159_ENABLE_WORKAROUND=0), however, this does not seem to work. Is there a correct way to disable this workaround?

I would like to run from a 128Mhz HFCLK, but this seems to cause issues. 

5. Prj - Here are my PRJ file configs.  I have attempted to disable QSPI NOR features. 

CONFIG_NRFX_QSPI=y
CONFIG_SPI_NOR=n
CONFIG_NORDIC_QSPI_NOR=n        # Enable SPI NOR flash support
CONFIG_PINCTRL=y

Any ideas on a solution to allow the QSPI peripheral to function correctly? I am concerned the NRFX QPSI is conflicting with the device tree QSPI settings.  Or perhaps I am missing critical configuration settings for the QSPI peripheral to allow it to read and write. 

[Edvin]

Hello,

Sorry for the late reply.

The QSPI HW on the nRF5340 is targeted for NOR flash. This means that there are some parts of the QSPI peripheral that is optimized for this, meaning it will increment some fields automatically. 

In short, you can only use the QSPI for external flash, and not for QSPI displays, unfortunately.

I guess the reason you are seeing the timeout is that it is waiting for a reply from the external flash, that doesn't come. It is a very limited instruction set that can be used. You can read about it in the QSPI documentation:

https://docs.nordicsemi.com/bundle/ps_nrf5340/page/qspi.html 

Best regards,

Edvin

[LukeC]

Evin,

I am aware the limitations of the QSPI peripheral.  Our display manufacturer copied the SPI flash op codes to make this display work with the Nordic QSPI peripheral.  

i have read the page you linked to.  I do not see any suggestions that any of those commands are waiting on specific responses from the SPI flash chip.  Am I missing something?  

For instance a "PP4O" command should just write data, correct? I do not see anything in the timing diagram mentioning that the peripheral is waiting on a SPI flash response(?).

[Edvin]

According to the instruction set, it is "Quad-Page program out. 

Are you trying to use this? Can you see whether the application reaches this command? (using a logic analyzer)

BR,
Edvin

[Edvin]

In general, compare - using a logic analyzer - the QSPI pins when using it for NOR flash (on the DK), and in your application. Does the NOR flash do something that is not being done by the display?

BR,
Edvin

[LukeC]

I think I made some progress.

My issue now is disabling the WRITE_ENABLE (0x6) and READ_STATUS(0x5) op codes during writes/reads.

1. Reads

The read command is sending the READ_STATUS (0x5) before the read command.  I am attempting to change the addressing mode to disable wipwait, but this does not remove the READ_STATUS op code. 

	add_config.wipwait = false;
	add_config.mode = NRF_QSPI_ADDRCONF_MODE_OPCODE;
	add_config.wren = false;
	nrf_qspi_addrconfig_set(NRF_QSPI, &add_config);

	uint8_t read_data[16] = {0};
	ret = nrfx_qspi_read(read_data, 16, LCD_SET_REG_ADDRESS(0x81));

	if (ret != NRFX_SUCCESS)
	{
		LOG_ERR("Error reading from QSPI %s", nrfx_error_string_get(ret));
	}

	LOG_HEXDUMP_INF(read_data, 16, "Read data");

2. Writes. Here is an attempt at a PP40 write. This has both ready and write enable commands before the 0x32 PP40 write. 

void qspi_write_first_line(uint8_t *data, uint16_t length)
{
	nrf_qspi_addrconfig_conf_t add_config = {0};

	add_config.wipwait = false;
	add_config.mode = NRF_QSPI_ADDRCONF_MODE_OPCODE;
	add_config.wren = false;
	nrf_qspi_addrconfig_set(NRF_QSPI, &add_config);

	uint8_t *ptr = malloc(length);

	if (ptr == NULL)
	{
		LOG_ERR("Error allocating memory");
		return;
	}

	memcpy(ptr, data, length);

	if (!nrfx_is_in_ram(ptr) || !nrfx_is_word_aligned(ptr))
	{
		LOG_ERR("Error memory alignment/location.");
		return;
	}

	nrfx_err_t ret = nrfx_qspi_write(ptr, length, 0x002c00);

	if (ret != NRFX_SUCCESS)
	{
		LOG_ERR("Error writing to QSPI, err = %s", nrfx_error_string_get(ret));
	}

	if (ptr)
	{
		free(ptr);
	}
}

[Edvin]

I see. Yes, those are part of the QSPI that makes it targeting NOR Flash chips. Not sure it it is possible to disable these, but using the nrfx drivers directly gives you the most amount of direct control, so if it is possible, you are on the right track.

Best regards,

Edvin