QSPI: Some operations do not return to idle (CS# high, SCK high)

[0xa000]

Test Environment (required)

• Platform: QMTECH Wukong Board
• Core Commit: 93e2eb8
• ROM Release: N/A

Describe the bug There are hardware assisted QSPI operations (ie. those implemented in sdcardio.vhdl) that keep the chip select (CS#) line asserted (low). In other words, these operations do not finish the SPI transaction they started. Most notable is the QSPI read operation (0x53).

To Reproduce Create a small test application that performs a hardware assisted read operation (0x53) and observe that the chip select line is still asserted (low). You will probably need an oscilloscope or custom VHDL to make this observation, as the chip select signal is not memory mapped at the moment, as far as I could tell.

Expected behavior All hardware assisted QSPI operations should return to the SPI "idle" state at the end of the operation, by driving both CS# (chip select) and SCK (SPI clock) high.

Additional context Interestingly, the SPI (not QSPI) implementation of the read operation does de-assert the chip select line, see sdcardio.vhdl line 4979 (state SPI_read_phase4). The same statement, ie. qspicsn <= '1', could be added to state QSPI_read_phase4 (line 4813 and further), where it is currently missing.

[gardners]

see src/tools/sdstates.c for a tool that can be used to help debug these state errors:

gcc -Wall -o sdstates src/tools/sdstates.c && ./sdstates < src/vhdl/sdcardio.vhdl > foo.dot dot -Tpdf foo.dot > foo.pdf && open foo.pdf

This reveals that the following state is a problem, which indeed looking at the code, it clearly is :)

     when QSPI4_write_phase2 =>
          if qspi_bit_counter = 0 then
            report "QSPI4: Sending byte $" & to_hstring(f011_buffer_rdata);
            qspi_byte_value <= f011_buffer_rdata;
          end if;
          -- XXX INCOMPLETE!
          sd_state <= Idle;

[0xa000]

Ah, nice! Earlier I created dotty graph of only the QSPI related states, but I'll definitely check this out. However, the QSPI4_ states are not being used as far as I can tell. For writing, QSPIqwrite is being used instead. See the VHDL around line 3100 where the various commands are handled.