NRX QSPI Issues on 5340

RE: NRX QSPI Issues on 5340

LukeC — Thu, 03 Apr 2025 17:08:10 GMT

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.

RE: NRX QSPI Issues on 5340

Turbo J — Thu, 03 Apr 2025 16:52:12 GMT

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.

RE: NRX QSPI Issues on 5340

LukeC — Thu, 03 Apr 2025 16:31:32 GMT

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?

RE: NRX QSPI Issues on 5340

Edvin — Fri, 21 Mar 2025 09:55:38 GMT

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

RE: NRX QSPI Issues on 5340

LukeC — Thu, 20 Mar 2025 18:00:33 GMT

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);
	}
}

RE: NRX QSPI Issues on 5340

Edvin — Wed, 19 Mar 2025 08:35:38 GMT

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

RE: NRX QSPI Issues on 5340

Edvin — Wed, 19 Mar 2025 08:34:19 GMT

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

RE: NRX QSPI Issues on 5340

LukeC — Tue, 18 Mar 2025 16:18:32 GMT

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(?).

RE: NRX QSPI Issues on 5340

Edvin — Tue, 11 Mar 2025 08:55:35 GMT

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