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]

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

[LukeC]

I am having an issue that I am worried is due to page size limitations. Here is what I see in the datasheet.

 

I am trying to send 640 bytes using 

NRF_QSPI_WRITEOC_PP4O

Here I try to write 640 bytes to address 0x002c00

uint8_t line_buffer[640];

void qspi_write_first_line(uint8_t *data, uint16_t length)
{

	memcpy(line_buffer, data, length);

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

	is_tx_done = false;
	nrfx_err_t ret = nrfx_qspi_write(line_buffer, length, 0x002c00);

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

	qspi_wait_interrupt();
}

However, I see this broken up into multiple writes and auto-increments the address.

Is this due to the page size limitations?

Is there a way to bypass the page size limitations or force this transmission?

[Turbo J]

Won't work, I recommend a redesign or just to use SPIM.

See PS Chapter 7.25.11.32 (register IFCONFIG0), where you can see that only 256 and 512 byte page sizes are supported by the QSPI peripherial.

[LukeC]

I can't redesign to use a single SPI, this is a VGA display and needs the throughput of QSPI.  The only options now are 1. Two-chip design of MCU + BLE or 2. Move to a different BLE SOC that has a more standard QSPI peripheral.