2024-10-15 11:33 AM
Hello all,
I have a very strange issue with QSPI peripheral. I am using it to store logs in external memory.
The flash that is used is MT25QL256ABA with a custom STM32WB55 board. I have connected PModSF3 using jumper wires that are at least 15cm long.
Issue: When I use the FAST READ (single data line, 1-1-1 mode), it works perfectly fine. I am able to validate it with the hex dump of a buffer that writes ASCII (0-9). But when I use it in QUAD OUTPUT FAST READ (1-1-4), I get some missing data that is probably shifted.
I have specified two dummy cycles based on the datasheet. Tried increasing it, does not make much of difference.
But reducing the clock speed by a factor of 100 seems to help, but then quad mode is useless.
The code is based mostly from the ST examples.
Can anyone help me in figuring out the issue? I can provide more data if needed.
static bool qspi_flash_read_fast_single_line(size_t address, uint8_t* pBuf, size_t length)
{
QSPI_CommandTypeDef sCommand;
dummy_cycles_cfg(&hqspi);
sCommand.InstructionMode = QSPI_INSTRUCTION_1_LINE;
sCommand.AlternateByteMode = QSPI_ALTERNATE_BYTES_NONE;
sCommand.DdrMode = QSPI_DDR_MODE_DISABLE;
sCommand.SIOOMode = QSPI_SIOO_INST_EVERY_CMD;
//! Send read command (Does not work)
sCommand.Instruction = 0x6B;
//! Address configuration
sCommand.AddressMode = QSPI_ADDRESS_1_LINE;
sCommand.AddressSize = QSPI_ADDRESS_24_BITS;
sCommand.Address = address;
sCommand.DummyCycles = DUMMY_CLOCK_CYCLES_READ; //< Two dummy cycles
//! Receive data configuration
sCommand.DataMode = QSPI_DATA_4_LINES;
sCommand.NbData = length;
if (HAL_QSPI_Command(&hqspi, &sCommand, HAL_QSPI_TIMEOUT_DEFAULT_VALUE) != HAL_OK)
{
CONSOLE_LOG("Failed to send read command");
return false;
}
if (HAL_QSPI_Receive(&hqspi, pBuf, HAL_QSPI_TIMEOUT_DEFAULT_VALUE) != HAL_OK)
{
CONSOLE_LOG("Failed to receive data in quad mode");
return false;
}
return true;
}
2024-10-21 02:12 AM
Thanks a lot for tagging these resources.
I will post an update as soon as some progress has been made.
2024-11-25 05:54 AM
I can confirm that it was the long jumpers that were causing the issue. The same code works perfectly fine on the custom PCB.