Zynq SPI timed out

[Enrico]

Dear All,

Me and a colleague of mine are facing an SPI timeout issue on a Zynq. We already posted the issue in the Xilinx forum: https://forums.xilinx.com/t5/Embedded-Linux/SPI-transfer-timeout/td-p/833550 but we did not receive any answer, yet. So I would like to ask your help.

I am trying to use a TFT LCD screen with the Digilent Artyz7, exploiting the frame buffer. I created a project on Vivado that exports the Zynq PS SPI interface through EMIO.

I have already deployed the linux-digilent kernel (v4.4.0) on the Zynq and I am able to see the SPI peripheral under /sys/class/spi_master/spi2.0 (the device tree has been generated using SDK). Thus, as soon as I try to insert the kernel module for the frame buffer support, I get the following error:

spi2.0: SPI transfer timed out

I attach the images from the logic analyzer:

 

 

 

The kernel module of the frame buffer sends the data correctly through the SPI interface before going to timeout state.

Any ideas or suggestions regarding this issue?

Thanks a lot.

Best Regards,

Enrico

 

[sbobrowicz]

Can you post the relevant device tree nodes? Are you setting num-cs in the spi node:

https://github.com/Digilent/linux-digilent/blob/master/Documentation/devicetree/bindings/spi/spi-cadence.txt

Also important, the node in which you are instantiating the LCD device (typically this should be done as a child to the SPI node).

I found an old xilinx forum post that might suggest you can fix this by tying the SS_IN pin of the EMIO SPI bus in the Vivado block diagram to '1'. I'm betting that was probably just addressing an old bug with the Vivado tools that didn't properly tie-off unconnected EMIO pins. Forum post here at the end of page 1:

https://forums.xilinx.com/t5/Embedded-Linux/Spidev-issue-Spi-transfer-timeout/td-p/548153

[morsucci]

@Enrico

 

Thanks for the question.

I have run into similar issues with the Zynq Spi driver in different kernel versions provided by Xilinx.

I think that the best option here would be to use the kernel for Petalinux v2017.4 provided by Xilinx on their github.

This is accomplished using the petalinux-config menu

Let me know if you have any questions about this process.

 

Also, keep me posted on whether this process fixes your bug.

 

Regards,

Mitchell

[Enrico]

Hi Mitchell,

thank you for your answer.

From this Xilinx web-page (https://www.xilinx.com/support/answers/70277.html) I saw that the Petalinux v2017.4 kernel is in the linux-xlnx git repository. Thus, I downloaded the tree and I moved to branch xilinx-v2017.4 before compiling the kernel (version 4.9.0). Anyway, the issue seems to remain also with this kernel version.

Trying to go deep into the spi-cadence kernel module, I found out that the system does not go inside the cdns_spi_irq (the interrupt service routine of the SPI controller). Thus, I guess the SPI transfer does not know when the transmission is completed and goes to timeout state.

Moreover, I put some printk in the code and suddenly the SPI tranfer worked for a moment. After reboot, the system acts as usual.

Do you have any other idea on this issue?

Thanks a lot for you support.

Regards,

Enrico

[Enrico]

Hi sbobrowicz,

thank you very much for your answer!

The TFT LCD screen is now working. The problem was the SS_IN left floating as you suggested.

Can you better explain me the reason why this pin creates the issue? Is it only a Vivado bug?

Thank you again.

Enrico

[JColvin]

Hi @Enrico,

My guess is that it is less of a Vivado bug and more of hardware bug, since this issue is not only limited to the TFT LCD screen. The internals of the LCD screen are probably expecting a constant value ('1' in this case) and don't handle a floating SS pin very well; our Pmod displays have the same issue. On a broader note, most electronics are not equipped to handle floating voltages very well so this issue will always crop up from time to time on other things as well. You always can't presume if something needs to be active low or active high either, so the tools (Vivado or the Arduino IDE or anything else) can't always catch and fix those things for you automatically.

Thanks,
JColvin

[amurices]

Hi guys @Enrico and @sbobrowicz,

I ran into an extremely similar issue, only I'm using a PL SPI interface instead of the PS. I posted the question here.

I wonder if either of you guys have any insight on what might be causing this. It seems the solution to my issue is different, as there's nothing unusual about my SS. SS_IN doesn't seem to be floating; its pin is always plugged to the correct pin in the SAMA.

I've been stuck on this all week. Hope you guys have any ideas.

 

[Musko]

The description of problem with wiring SPI via EMIO and SS_IO pin is in TRM chapter 17.5.4 (see IMPORTANT: note). The SS_IO pin is declared as signal type inout (bidirectional). See Vivado HDL processing_system7_0 wrapper file. It depends how you export SPI signals in Block Design, by default they are grouped together and exported as interface. The input part (SSIN) is used by Zynq SPI Master controller to detect multi-master mode. Have it float, the SPI Master controller can false detect multi-master mode.

Note that Vivado Block Design validate will warn you with: WARNING: [#UNDEF] When using EMIO pins for SPI_0 tie SSIN High in the PL bitstream.

One solution is to tie SSIN input to '1' (as described in Figure 17-8 in TRM) but you need to open and modify the Vivado HDL processing_system7_0 wrapper file, or export Zynq SPI pins as single signals and tie them in your top design.

The other option is that on your HW you have an external pull up on this pin.

The option I use (if HW does not have external pull up on this pin) is to add PULLUP constrain in xdc file (e.g. set_property -dict {PACKAGE_PIN M15 IOSTANDARD LVCMOS33 SLEW FAST DRIVE 8 PULLUP TRUE} [get_ports {spi0_ss_io}]).

Another thing to mention here regarding possible problems for SPI via EMIO is that SPI max clock rate is lower (25Mhz vs 50MHz via MIO pins).