Describe the bug
When using hardware assisted QSPI operations, the result of the first read operation following certain other operations contains 4 bytes of garbage values. This is caused by the QSPI state machine (see sdcardio.vhdl) skipping over the required 8 dummy / latency cycles. (Basically, the first 8 SPI clock cycles after a read command output garbage, since it takes a bit of time to fetch the actual data from the flash.)
The dummy cycles are skipped because the spi_no_dummy_cycles signal is set to '1' by certain commands, but is not reset to '0' after those commands have finished. The first read command thereafter effectively runs with spi_no_dummy_cycles set to '1'. The commands that cause trouble are potentially all those that set spi_no_dummy_cycles to '1'. The most common of these are the 256 and 512 byte page programming commands (0x54 and 0x55).
NB. The verify operations (0x56) explicitly sets spi_no_dummy_cycles to '0'. A quick fix would be to update the read operation (0x53) to do the same. This is somewhat of a hack in my view, though, because I think the operations that set spi_no_dummy_cycles to '1' are responsible for resetting it to '0'.
To Reproduce
Create a small test program that uses hardware assisted operations to erase a sector, program a single 256 byte page, and then perform a read. Observe the first four bytes returned by the read operation do not match the programmed bytes.
Expected behavior
The hardware assisted QSPI read operation should always return the data present in flash memory, independent of which operations were performed before it.
Test Environment (required)
Describe the bug When using hardware assisted QSPI operations, the result of the first read operation following certain other operations contains 4 bytes of garbage values. This is caused by the QSPI state machine (see sdcardio.vhdl) skipping over the required 8 dummy / latency cycles. (Basically, the first 8 SPI clock cycles after a read command output garbage, since it takes a bit of time to fetch the actual data from the flash.)
The dummy cycles are skipped because the
spi_no_dummy_cyclessignal is set to '1' by certain commands, but is not reset to '0' after those commands have finished. The first read command thereafter effectively runs withspi_no_dummy_cyclesset to '1'. The commands that cause trouble are potentially all those that setspi_no_dummy_cyclesto '1'. The most common of these are the 256 and 512 byte page programming commands (0x54 and 0x55).NB. The verify operations (0x56) explicitly sets
spi_no_dummy_cyclesto '0'. A quick fix would be to update the read operation (0x53) to do the same. This is somewhat of a hack in my view, though, because I think the operations that setspi_no_dummy_cyclesto '1' are responsible for resetting it to '0'.To Reproduce Create a small test program that uses hardware assisted operations to erase a sector, program a single 256 byte page, and then perform a read. Observe the first four bytes returned by the read operation do not match the programmed bytes.
Expected behavior The hardware assisted QSPI read operation should always return the data present in flash memory, independent of which operations were performed before it.