Hello,
Thank you for the update.
Thank you for your response.
Looking at the datasheet for REG_SPI_WIDTH Definition:
Bit 2: Extra dummy on SPI read transfer. Writing 1 to enable one extra dummy byte on SPI read transfer.
Bit 1 - 0: SPI data bus width: 0b'10: 4 bit (Quad-SPI)
I would need to send: 00000110 (0x06)
Correct?
In the FT9xx code, it looks like '4' is being sent:
// Turn on FT9xx quad-SPI.
spi_option(SPIM, spi_option_bus_width, 4);
Yes this is correct, to just enable Quad SPI mode on EVE you would write 2 (dec) to the REG_SPI_WIDTH register, to also enable the extra dummy byte you would write 6 (dec) to the register.
As for the spi_option() command, this is a FT9xx API command which is being used to configure the SPI mater interface on the MCU, you can find details of this command in Section 2.15.3.11 of the
FT9xx API Programmers Manual. Essentially this is being used to set the interface to Quad SPI on the master.
I have attached a capture (Capture.PNG) of a REG_HSIZE write and subsequent read in QPSI mode for reference, were looking for the following values on the trace:
REG_HSIZE = 0x302034
Bin = 0011 0000 0010 0000 0011 0100
Bin (with write bit) = 1011 0000 0010 0000 0011 0100
Value = 800
Bin = 0000 0011 0010 0000
Bin (with endianness applied) = 0010 0000 0000 0011
Note: in this configuration I was using the FT9xx as the SPI master and we only need to utilise a single dummy byte during the read phase due to implementing a slow SCLK rate, for higher SCLK rates we would enable the extra dummy byte. The read and write addressing phases are send in 24 bit transactions with the 22 bit address appending the read (00) or write (10) bits.
Could you please clarify what the clock rate of your SPI master is?
The reason I ask is because in the Programming Guide (page 12) for Quad SPI, it says when reading, you have to send:
WR/Address -> Address -> Address -> Dummy -> Data -> Data...
Trying to wrap my head around this, I set REG_SPI_WIDTH, TFT_write8(REG_SPI_WIDTH, 6);
This should switch into Quad SPI mode, correct? I then immediately try to read the REG_SPI_WIDTH out to make sure I can successfully read something, kind of like initially reading the Chip_ID:
Yes I believe your write should configure EVE into QPSI mode, do you then subsequently configure the SPI master interface into QSPI?
uint8_t TFT_read8(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
uint8_t retData[2] = {0}; // Array to hold the received ID
if (HAL_QSPI_Receive(&hqspi, retData, HAL_QSPI_TIMEOUT_DEFAULT_VALUE) != HAL_OK)
Error_Handler();
uint8_t data = retData[1];
return data;
}
This however does not work, it either hangs waiting for a response or ends up in the Error_Handler(). I think I have what needs to be sent correct. Referencing the Programming Guide:
4.1.3 Host Memory Read
For SPI memory read transactions, the host sends two zero bits, followed by the 22-bit address. This is
followed by a dummy byte. After the dummy byte, the BT817/8 responds to each host byte with read
data bytes.
Do you see anything obvious that I have wrong?
Have you configured the read function to use a dummy byte? I note the following line in your typedef for the address write:
sCommand.DummyCycles = 0; // No dummy cycles
What is HAL_QSPI_Receive() function doing? (I'm looking to clarify where the dummy bytes are enacted on the master side)
Do you have a logic analyser to hand? it may be useful to scope the SPI traces during initialization so that you can observer the bus activity.
I can provide a SPI trance of the BRT_AN_025 code configuring EVE into QSPI if you believe this would be useful to you?
Best Regards,
BRT Community