03-09-2018 03:04 AM
I am trying to read and write to a flash device using QSPI on Zynq device.
The number of clock cycles that I see on the SPI bus is not what I am expecting and I am out by one byte but do not understand why.
This is the sequence of what I am doing:
What I expect is to see (48 clock cycles):
But after step 2 I only see 6 cycles. Why?
What may be related:
03-20-2018 06:42 PM
It sounds like you are using a single QSPI chip and not 2 in //.
1 - Only 24 bit address is supported. For 32 bit addressing you have to set-up the QSPI extended address register.
2 - From what I've observed, the dummy byte(s) insertion is done using the width of the data transfer. In your case, if it's a single chip, each dummy byte corresponds to 2 dummy 4 bit read cycles. When it's 2 chips in //, each dummy byte becomes a single dummy cycle.
About 2 - because a few chips when set for max rate can only be programmed to use an odd number of dummy cycles, we've skipped trying to use the QSPI controller do deal with the dummy cycle insertion.
Instead our driver reads (with zero dummy cycles) the 1,2 or 4 bit data, and in S/W inserts them in a shift register skipping the equivalent number bits to match the number of dummy cycles before "recording" the real data.
03-20-2018 10:21 PM
Yes, I am only using a single QSPI chip.
I understand that it would be best if I added dummy cycles myself but it does look like the Zynq's QSPI peripheral is adding a dummy cycle, or something, and it does not make sense to me. If I knew exactly what it was doing, then I could easily work around it.
I still do not understand why I see 6 cycles (in the dummy phase) where I expected 8. If the single dummy cycle is done in quad mode, then it should be 2 cycles.
Is there any way that you can explain how the two writes to TXD0 result in 46 clock cycles?
03-21-2018 10:18 AM
Did you match the number of dummy cycles used by the QSPI controller with the value set in the QSPI chip?
The chip will output the data after the number it has been programmed with, no matter what the controller uses.
The QSPI controller dummies are only for skipping the non-data.
03-21-2018 10:59 AM
No, my QSPI chip and controller does not match. That is my problem, and I do not understand why.
Writing to TXD0 will always transfer 4 bytes. I am writing to TXD0 twice, so it must be 8 bytes. It is a QSPI write, so the controller should interpret the command, insert a dummy cycle, and switch to QSPI mode after that. If this was the case, then I would see:
1. 1-byte command = 8 cycles.
2. 3-byte address = 24 cycles.
3. 1-byte dummy = 8 cycles in SPI mode, 2 cycles in QSPI mode.
4. 4-byte data in QSPI mode = 8 cycles.
I am not sure about what the controller does in step 3. The datasheet is not clear, but as far as I can tell it can be one of:
a. Do not insert a dummy cycle= 0 cycles.
b. Insert a dummy byte in SPI mode = 8 cycles.
c. Insert a dummy byte in QSPI mode = 2 cycles.
If I add the cycles from steps 1,2 and 4, then I get 40 cycles (do I already have it wrong at this point)? Then, if I use the 3 possibilities from a, b and c, then I can get 40 cycles, 48 cycles or 42 cycles. But I am getting 46. Where am I going wrong?
Thanks for helping.
03-21-2018 05:44 PM
The SPI clock is entirely controlled by the data in the TX FIFO.
Even when inserting dummy bytes, data from the TX FIFO is "pulled out"
04-04-2018 07:49 AM
You can manually program the number of dummy cycles the QSPI uses during read operations by using 'register write'. Commonly QSPI flashes lets you program it both as non-volatile and as volatile. You may check your QSPI flashes datasheet and search for configuration registers.
-also check if the default value of dummy-cycles, may be it is actually 6.