cancel
Showing results for 
Search instead for 
Did you mean: 
Contributor
Contributor
282 Views
Registered: ‎09-11-2018

XST_SPI_COMMAND_ERROR when sending command to QSPI flash

Jump to solution

I am using SDK 2018.3, with spi_v4_4 xspi library, for a 32bit MicroBlaze on a Artix7.

I configured the QSPI for interrupt based SPI master mode, according to the Winbond flash example on the Xilinx github repository.
https://github.com/Xilinx/embeddedsw/blob/master/XilinxProcessorIPLib/drivers/spi/examples/xspi_winbond_flash_quad_example.c 

I partially modified it to match the ISSI IS25LP064A flash I am using.

Now, as soon as I send the command to erase a sector, the SPI status handler I registered gets called,
and the status is: .
I sent the command to erase a 4K region in the flash - 0xD7, not 32K like in the winbond example, because it suits my requirements more.
The QSPI module shouldn't care about what content it sends to the SPI slave... ?
What could be the reason for the "command error"?

EDIT:
I changed the command to 0x20 now instead of 0xD7, and I get further in the program. I don't understand why - how is it the SPI master hardware's business to interfere with / care about the bytes I am sending to a slave? I've never seen this "feature" on any MCU I ever programmed.

Now I get the XST_SPI_COMMAND_ERROR after sending the QuadReadFast command, 0x6B, which should be supported according to this thread:
https://forums.xilinx.com/t5/Welcome-Join/AXI-Quad-SPI-Command-Error/td-p/552294 

Is there something else I could do wrong with regards to sending the command, other than using a "wrong" command byte itself, that will result in a XST_SPI_COMMAND_ERROR ?

EDIT 2:
Would it be possible, from the way the library works, that one transmission can be interpreted as more than one command, e.g. if I initiate a fixed-length command, but Transmit with a bytecount higher than the length, and it somehow interprets the excess data as new command, resulting in the "command error", but from my program flow it only looks like the "fast quad read" was the culprit?
It currently does not look like that is the case, but I'm trying to find an explanation for a "command error" I  get despite apparently there being no problem withthe 0x6B command.
(this question only makes sense if I got that right, from my second link, where it reads to me like the QSPI hardware itself is doing the check for "allowed commands". Not the slave device (since SPI has no ACK or something like it, I don't see how the QSPI could know about the slave device not "liking" a certain command anyway, so it has to be that way around?))

Tags (4)
0 Kudos
1 Solution

Accepted Solutions
Highlighted
Contributor
Contributor
175 Views
Registered: ‎09-11-2018

Re: XST_SPI_COMMAND_ERROR when sending command to QSPI flash

Jump to solution

Ok, looking at the correct document for the specific IP core used, it seems that the only quad-reading command, in this... "quad spi" module, supported is quad IO read - for XIP mode only, i.e. to execute code from flash, not to just read it back for other uses.
(I saw some older thread earlier where someone had a similar problem, but that was apparetnly not exactly the same SPI core - where they mentioned the 0x6b command as supported, and isn't working for me here.)

In the document axi_quad_spi_v3_2_pg153, on page 58, Table 3-2: Supported Commands in Quad Mode and Mixed Mode Memory , it says that the only data read command supported in quad mode is 0x03: single-line SPI normal read...
Using the normal read command, it works; albeit 4 times slower than initially expected.

 

View solution in original post

0 Kudos
1 Reply
Highlighted
Contributor
Contributor
176 Views
Registered: ‎09-11-2018

Re: XST_SPI_COMMAND_ERROR when sending command to QSPI flash

Jump to solution

Ok, looking at the correct document for the specific IP core used, it seems that the only quad-reading command, in this... "quad spi" module, supported is quad IO read - for XIP mode only, i.e. to execute code from flash, not to just read it back for other uses.
(I saw some older thread earlier where someone had a similar problem, but that was apparetnly not exactly the same SPI core - where they mentioned the 0x6b command as supported, and isn't working for me here.)

In the document axi_quad_spi_v3_2_pg153, on page 58, Table 3-2: Supported Commands in Quad Mode and Mixed Mode Memory , it says that the only data read command supported in quad mode is 0x03: single-line SPI normal read...
Using the normal read command, it works; albeit 4 times slower than initially expected.

 

View solution in original post

0 Kudos