Honored Contributor
Honored ContributorI am not sure what you mean by enabling the CS because there is no such control in the SPI.
Do you mean setting the slave to select in the SER register? If so, this does not directly lower the CS. It's the controller that will drive the 4 CS lines with the inverse of the SER register when the transfer is started. The CS goes low When the first frame is written in the TX FIFO and stays low until the FIFO is empty. It's explained in the handbook (SPI master section / data transfer subsection: The SPI master starts data transfers when all the following conditions are met: ■ The SPI master is enabled ■ There is at least one valid entry in the transmit FIFO buffer ■ A slave device is selected What are you checking when polling? The FIFO level, or the status register bit indicating the TX FIFO empty, or the one indicating the TX FIFO full? If you are sending less than 256 frames there are no needs to do any check. Do non-stop writes, the FIFO will absorb all the data.
New ContributorI would like to dust off this thread and provide some observations I have made over the past couple of days of troubleshooting.
I am using the HPS SPI master to communicate with a slave device that requires the chip select to remain asserted during the entirety of a read or write transaction. I too came across the issue of the SPI controller de-asserting the chip select after each byte. A transaction with the slave device occurs as follows, one byte of opcode is sent by the master to tell the slave device what address is being accessed, as well as if the transaction is a read or write, then 2 bytes of data are sent. All of this happens while the chip select is asserted.
I have found that at higher baud rates the SPI controller is unable to keep the chip select asserted if anything other than a 16-bit transfer is selected. In the Intel Cyclone V HPS tech reference (page 20-18) it states that there are 2 SPI modes that support continuous transfer. The mode with SCPH = 1 and SCPOL = 1 asserts the slave select for the duration of the transfer. Again, at higher bit rates this does not appear to work for transfers that are not 16-bits.
I have attached logic analyzer screen captures showing the SPI interface running with an SCK of 5MHz and 10MHz, 8-bit and 16-bit transfers. You can see that at 10MHz the chip select is de-asserted for an 8-bit transfer, but held asserted for 16-bits. At 5MHz the chip select remains asserted for the entire transfer. This is fine for my application, I can deal with the lower bit rate. And I don't have to substitute a GPIO to accomplish the same thing.
I hope this information is helpful. If someone can verify this and reply that would be great.
