Quad SPI Single Mode Read Chip ID from Riverdi

[kumaichi]

Hello,

I'm using a Nucleo-WB55RE board with Quad SPI in single mode.  I'm trying to start very simply by just reading the chip id from a Riverdi BT81X display.  I have captured two waveforms, one via a Nucleo-446 board using regular SPI and one from the WB55.

My QUAD SPI settings are as follows:

Per the datasheet, REG_ID is at address, 302000h:

This is my function to try and retrieve the chip id, everything is hard coded at the moment, just trying to understand the process of using the Command and Transmit/Receive functionality.  The datasheet 

uint8_t TFT_qspi_read_id()
{
	uint8_t pData[4] = {0x00};
	QSPI_CommandTypeDef sCommand = { 0 };

	/* Enable Reset --------------------------- */
	sCommand.InstructionMode = QSPI_INSTRUCTION_1_LINE;
	sCommand.Instruction = 0x30;
	sCommand.AddressMode = QSPI_ADDRESS_NONE;
	sCommand.AlternateByteMode = QSPI_ALTERNATE_BYTES_NONE;
	sCommand.DataMode = QSPI_DATA_1_LINE;
	sCommand.DummyCycles = 0;
	sCommand.NbData = 4;
	sCommand.DdrMode = QSPI_DDR_MODE_DISABLE;
	sCommand.SIOOMode = QSPI_SIOO_INST_ONLY_FIRST_CMD;

	if (HAL_QSPI_Command(&hqspi, &sCommand, HAL_MAX_DELAY) != HAL_OK)
		Error_Handler();

	uint8_t data[4] = {0x20, 0x00, 0x00, 0x00};
	if (HAL_QSPI_Transmit(&hqspi, data, HAL_MAX_DELAY) != HAL_OK)
		Error_Handler();

	if (HAL_QSPI_Receive(&hqspi, pData, HAL_MAX_DELAY) != HAL_OK)
		Error_Handler();

    return *pData;
}

Looking at the captures, I can see that 0x7C is in fact coming back from the Transmit call but sending the receive doesn't return the value.

Any ideas of what I can try to figure this out?

Kindest regards.

[Pavel A.]

To read the ID you need only HAL_QSPI_Receive, no transmit. Remove the transmit.

But this is to read the standard ID data. If you want to read the register located at some address, do specify its address. Ex.  sCommand.AddressMode = QSPI_ADDRESS_1_LINE; sCommand.AddressSize = QSPI_ADDRESS_24_BITS; sCommand.Address = 0x302000; s_command.NbData = 1;

[kumaichi]

Thank you, Pavel, for your reply.  I tried the sample you've given, and it fails when sending the command.  After 6 days of working on this, the only way I could get it to work, which feels very hackie, is with:

The value being passed into the method is, 0x00302000

uint8_t TFT_qspi_read_id(uint32_t const address)
{
	QSPI_CommandTypeDef sCommand = {0};

	// Set up the command structure
	sCommand.InstructionMode   = QSPI_INSTRUCTION_1_LINE;   // Instruction sent over 1 line
	sCommand.Instruction       = (uint8_t)(address >> 16U);	//Get the first byte, should look like 0x30
	sCommand.AddressMode       = QSPI_ADDRESS_1_LINE;       // Address sent over 1 line
	sCommand.AddressSize       = QSPI_ADDRESS_16_BITS;      // Try using 16-bit address
	sCommand.Address           = address & 0xFFFF;          // Mask off the first byte and keep the last two bytes
	sCommand.DataMode          = QSPI_DATA_1_LINE;          // Data mode for receiving ID
	sCommand.NbData            = 2;                         // Expecting 2 bytes (for ID)
	sCommand.DummyCycles       = 0;                         // No dummy cycles
	sCommand.DdrMode           = QSPI_DDR_MODE_DISABLE;     // Disable DDR mode
	sCommand.SIOOMode          = QSPI_SIOO_INST_EVERY_CMD;  // Send instruction every command

	// Send the command (instruction and address)
	if (HAL_QSPI_Command(&hqspi, &sCommand, HAL_QSPI_TIMEOUT_DEFAULT_VALUE) != HAL_OK)
		Error_Handler();

	// Now receive the data (chip ID)
	uint8_t id[2] = {0};  // Array to hold the received ID
	if (HAL_QSPI_Receive(&hqspi, id, HAL_QSPI_TIMEOUT_DEFAULT_VALUE) != HAL_OK)
		Error_Handler();

	char value[50] = "";
	sprintf(value, "Chip ID: 0x%02X\n", id[1]);

    return id[1];
}

I also had to change the Fifo Threshold = 1. 

It would be extremely helpful in CubeMX if you were presented with "real" assistance.  When you click on Fifo Threshold you get:

Fifo Threshold
Fifo Threshold must be between 1 and 32.

Yeah, that's real helpful.  You end up spending an hour trying to find what the heck a Fifo Threshold is and what to set it too.

Also, curious how many minutes, hours, days, weeks, etc... everyone has spent closing the windows that open every time you debug or run via STM32CudeIde, is there a way to keep those files from opening?

Thanks again for your help and if there is another way than what I provided I would certainly be interested, like I said, the way I got it work seems a little hackie, but I guess that just might be the way it is, I don't know.

Kindest regards

[Pavel A.]

Sorry I've lost the point that the device on QSPI is not a flash or other memory chip. Then of course the vendor documentation should describe the QSPI protocol.

[AScha.3]

Hi,

the EVE chip has a SPI interface - not qspi !

Or what you see in ds ? Just show.

And tell : which display and EVE chip and interface ?

[kumaichi]

Hello @AScha.3, thank you for your response. 

As per the DS and the Programming Guid the BT817Q supports Quad SPI. 

I'm using the Riverdi RVT50HQBNWC00-B display which contains the BT817Q EVE4 chip.  I currently have the display connected to the QUADSPI port of the Nucleo-WB55RG board.  I was trying to confirm that I could "talk" to the display by getting the ChipID.  Once that connection is made, then I need to set the REG_SPI_WIDTH to tell the chip to operate in Quad SPI mode.  I think this is going to be a very difficult task.

Kindest regards

[AScha.3 · Accepted solution]

Hi,

so you connected this:

1. You have to use transmit-receive call, on SPI connection you cannot separate send and receive, it happens always same time .

2. Try first with standard 1-line data  SPI (CS, clk, miso, mosi ). This you have to get running first.

(I have it running > 1 year , all time, no problems. )

3. The Q-spi on STM cpu is for flash/memory chip , see timings in ds , it might not work with EVE chip at all.

4. TFT update with standard spi at 16Mbit speed is < 1ms , with dma use, almost no cpu time needed. So no need, to use "faster" q-spi (if possible at all with memory-q-spi-interface) - you gain nothing.

[kumaichi]

I currently have it connected per the Riverdi DS:

I initially was trying to get single mode running because the CMD section is only accessible through single spi and then I was going to switch it to Quad SPI and get that working. But yes, I agree, trying to get this to work has become a time suck and as you said, running it via QSPI doesn't really buy anything.  Thank you for pointing that out.

Kindest regards