How to use SPI_0 Fabric I/O as Master

[Jan2233444]

Hello,

I'm trying to use the fabric IO for the SPI_0 interface on the MSS so that I can have the SPI signals mapped to pins on the FMC connector (for the video kit). I'm a bit unsure on how to properly setup the Libero diagram so that SPI_0 can act as a master since the signals exposed suggest a slave setup.

I've tried tying SS_F2M input low and connecting CLK_F2M to a 50 MHz ref clk, though nothing seems to come out on CLK_M2F with this setup. I've also tried selecting the Fabric I/O option for target select 1 and connecting the generated SS1_M2F signal to output to see if there would be any change.

The SPI_LOOPBACK reference design example uses SPI_1 with the MSS I/Os as the master and shows SPI_0 with Fabric I/Os as the slave, so I wanted to know what would be the proper way to set up SPI_0 to act as a master or what resources might exist to give more information on this. Thank you.

[JV73]

I've been working with MSS_SPI_0 this week and have made the following observations. In Libero 2024.1, with MSS_SPI_0 enabled and all pins (including SS1) routed into the fabric: only SS1 shows up on the MSS component within Libero (SS0 is mysteriously missing). SS1 is present, but using the BareMetal drivers with MSS_SPI_SLAVE_1 to INIT and 'select' device 1 does NOT work. Turns out tho, that using MSS_SPI_SLAVE_0 in the driver and connecting SS1 to the outside word does work. A bug report has been filed for this.

[Jan2233444]

Thank you for your response. Have you ever tried using MSS SPI 0 within the embedded Linux environment? For me it still does not work right with SPI slave 1 used. I've tried using DO_OE as the CS instead, which seems to communicate with the device fine allowing for a response on the DI line yet the Linux image still is not recognizing this response.

[hughbreslin]

@JanicaD The Icicle Kit reference design has a working implementation of the SPI controller that is used with Linux which might be worth using as a reference

[Jan2233444]

Thank you for your response as well. The SPI interface works as expected when using the baremetal example, and SS1 gets pulled low when MSS_SPI_SLAVE_0 is selected in the bare metal code as JV73 mentioned. Though when the Linux image is booting and it initiates a SPI transaction, SS1 does not get pulled low even though a clk signal is generated and data is generated on SPI_0_DO_M2F. It seems that the SS signal is not getting activated, which could explain why the data read on the Linux image remains 0 even when data is coming in on SPI_0_DI_F2M (from when I used DO_OE signal to connect to my peripheral's SS). I followed the icicle kit SPI_LOOPBACK reference design and connected SPI_0_SS1_M2F to an output port and to SPI_0_SS_F2M.

[eppidei]

Hi @Jan2233444 as temporary workaround set bit8 and bit9 of slaveselect at 0.

[Jan2233444]

Hi @eppidei, thank you very much for your suggestion. Writing 2 to the slave select register (to use the slave select at the FPGA fabric interface) worked in allowing the SS1 signal to go low during a transaction. Though when I initiate a message receive using spidev to test the SPI0 interface, it still only reads 0's even though there is data coming on DI (confirmed with Identify Debugger). BareMetal code works as expected with read and write transactions, though with Linux it seems to still work with transmit but only receive 0's regardless of incoming data on DI. Do you happen to have any other suggestions on what may be causing this issue? I checked through the rest of the SPI register values and nothing seemed abnormal.

[eppidei]

Hi @Jan2233444 , can you please try to use the BIT(0) of the slave select (write 1 instead of two).

[Jan2233444]

@eppidei Yes, I just tried writing 1 to that register and now it's the same as previously where the SS1 signal (SPI_0_SS1_M2F) does not go low during a transaction though the clk signal is still generated. Additionally, after performing a SPI transaction the register seems to automatically reset to 0, even though 1 was just written to it

[Jan2233444]

Thank you all for your help, the primary issue was in my device tree configuration for the SPI device

[Tom-System]

@Jan2233444 Hello, I have exactly the same problem with the SPI interface as you described. Can you explain your solution in the device tree configuration? It would help me fixing the issue at my side or at least check if my configuration is correct.

[Jan2233444]

@TomVerbeeckHeist Hello, one of my issues was that I was using CS 0 rather than CS 1, so make sure that in your device tree reg = <1> rather than reg = <0>.

[Tom-System]

@Jan2233444 Hello, I modified the reg parameter in my device tree but still no result. As you also described in your comments the incoming SPI data is also not received using the linux 'spidev_test'-command although the data is set on the DI line from the slave device to the master. So I was wondering if you could make it to work with the Linux kernel implementation? On the low level end it's working. To be more specific, the value in address 0x2010801C, SPI0 in this case, should be 0x202 to get the CS functional. I can also read the data for the RX_DATA register which means that the SPI IP in the SoC is receiving the data. It's the linux driver that is not mapping things correctly. I didn't check the bare metal implementation but will probably work. What did you implement in your device tree for SPI0 or SPI1? Maybe I'm missing a parameter.
I did the same SPI implementation on Linux with a Xilinx Zynq FPGA which is working fine.