cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
1,147 Views
Registered: ‎06-22-2011

AXI Quad SPI read timeout

Jump to solution

I'm having problems with what I believe is a standard implementation of the Xilinx AXI Quad SPI module, v3.2.

Summary:
We can write ok, but reads generate a timeout error. We see the expected behaviour for writes and reads by observing the spi clk, mosi, miso and slave select signals at the PCB level.

Background information:
- We're using Vivado and Petalinux 2019.2 in an Ultrascale XCZU3EG device
- The Zynq MPSoC connects via AXI lite to the quad spi module
- The Zynq MPSoC is SPI master
- The ip2intc_pc interrupt from the AXI Quad SPi connects to the ps_pl_irq pin of the Zynq MPSoC

To summarise the issues:
1. The device tree generated as a result of the exported XSA shows the ip2intc_irpt interrupt
2. We can see the spi-xilinx controller requests a interrupt from the device tree and successfully registers it (it maps to IRQ vector 51 in Linux)
3. When we use the scope we can see the interrupt going active high when a SPI transfer is initiated. In fact it stays high, presumably because the driver is not detecting the IRQ so it doesn’t clear the register value to disable it.
5. The function registered to that interrupt (xilinx_spi_irq) in spi-xilinx is never called, and we end up getting a “SPI timed out” error.

As a sanity check I can run cat /proc/interrupts and see that the interrupt count does not increase for vector 51.

On the scope we can see bits being written and bits coming back, so writes succeed despite the error, but because of the time out error the contents of the read do not make it to userspace.

Thanks in advance.

Tags (4)
0 Kudos
1 Solution

Accepted Solutions
960 Views
Registered: ‎06-22-2011

We made a baremetal application that would write to the PL SPI device then read the returned bytes on interrupt and this worked. Comparing the HW definitions generated for the baremetal app (xparameters.h) to the device tree generated for Petalinux, we found that the interrupt numbers were different - where the baremetal app defined an SPI interrupt at 125, the generated device tree defined it at 122 (written 90 + the 32 reserved interrupts). Replacing the generated interrupt numbers with the ones in the baremetal app fixed the problem, giving us working SPI reads.

This raises another question - how do we check if the interrupts in device tree are being generated correctly? In this case we compared to the generated source in Vitis, but given the interrupt numbers are generated from the XSA coming out of Vivado, is there somewhere within Vivado or the extraction of the XSA where we could find the correct numbers with less faff?

 

View solution in original post

Tags (1)
0 Kudos
7 Replies
abommera
Xilinx Employee
Xilinx Employee
1,121 Views
Registered: ‎10-12-2018

Hi rdf@plextek.co.uk ,

In order to make sure there are no issues with AXI QSPI IP and Zynq MpSoC interface, Can please run a bare-metal interrupt example?

https://github.com/Xilinx/embeddedsw/tree/master/XilinxProcessorIPLib/drivers/spi/examples

 

Thanks & Regards
Anil B
-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
1,108 Views
Registered: ‎06-22-2011

Hi Anil B,

Thanks for the reply. I'll see if I can get a software engineer to try this. (I'm a hardware guy).

Regards,

0 Kudos
974 Views
Registered: ‎06-22-2011
We have run a bare metal app and can see that the interrupt is asserted and then cleared.
This is different to running it under Petalinux where the interrupt is asserted but never cleared.
0 Kudos
961 Views
Registered: ‎06-22-2011

We made a baremetal application that would write to the PL SPI device then read the returned bytes on interrupt and this worked. Comparing the HW definitions generated for the baremetal app (xparameters.h) to the device tree generated for Petalinux, we found that the interrupt numbers were different - where the baremetal app defined an SPI interrupt at 125, the generated device tree defined it at 122 (written 90 + the 32 reserved interrupts). Replacing the generated interrupt numbers with the ones in the baremetal app fixed the problem, giving us working SPI reads.

This raises another question - how do we check if the interrupts in device tree are being generated correctly? In this case we compared to the generated source in Vitis, but given the interrupt numbers are generated from the XSA coming out of Vivado, is there somewhere within Vivado or the extraction of the XSA where we could find the correct numbers with less faff?

 

View solution in original post

Tags (1)
0 Kudos
xiayanqian
Participant
Participant
562 Views
Registered: ‎08-26-2020

Hello, rdf. I think i am facing a similar problem.

Would you tell me how to check the "SPI interrupt" in xparameters.h? I mean, what's the name of this interrupt. We used the same device and the same interrupt connection.

Sorry for the newwbie question, looking forward to your reply.

0 Kudos
501 Views
Registered: ‎06-22-2011

The SPI Interrupt number is a #define from xparameters.h in the bare metal app. In device tree we replaced the generated interrupt numbers with the ones from the baremetal app 

0 Kudos
xiayanqian
Participant
Participant
333 Views
Registered: ‎08-26-2020

Hello,I figured out what caused my axi quad spi "transfer timed out" problem. Sorry for disturbing you, I think this may help someone else so I decide to post it here.

I enabled the FIFO(size=16) in the axi quad spi IP setting and no more "transfer timed out", then I use the analyzer to check the io0_o(MOSI out) ,the signal showed that Master output worked fine, but when I checked the io1_i(MISO), it was always 0x00, this means Master can not get any response signal from the Slave.

Finally I checked the ss_io signal(CS/SS,slave select) and found: the ss_io changed when the master transfered just 1 bit, the command is made up of 8 bit, so the Slave couldn't get a complete command, so there was no response.

I set the ss_io to constant 1, this means the Slave is always selected, and then Master can get correct response. 

I am using Linux OS,the kernel driver "User mode SPI device driver support" in petalinux may have some bug, looking forward someone can solve the ss_io problem from software aspect.

0 Kudos