Can you please attach your firmware? How frequently are you seeing the drop outs? (According to your last post, you mean that when you send 4 bytes in the firmware, you are seeing only 3 bytes going out on MOSI. Please confirm)
I'm the firmware engineer working with Fernando on this.
I've attached the code function we repeatedly call to read the SPI Flash memory
We are driving the SPI in register mode by sending a 4 byte command to the memory and then reading the data out.
Fernando's traces seem to show that sometimes the 4 byte read command is truncated to 3 bytes which confuses the memory and it returns the data from the wrong address.
Its takes about 1500 calls to our function to read all the data we want from the memory.
With SDK 1.3.4, we get a single error every two or three attempts at reading the memory.
ie we get one SPI transmission error every 3000/4000 calls to CyU3PSpiTransmitWords().
I have hacked the SDK to use the cyu3lpp library from SDK 1.3.3 and the problem goes away.
( No errors in over 1.5 million calls to CyU3PSpiTransmitWords() )
Embedded Software Engineer
spiReadBytes.c.zip 399 bytes
I have attached the modified libcyu3lpp.a file.
Password for the attachment: cypress
Can you please replace the same file which is currently linked in your application and test?
debug_release_versions.zip 301.0 K
I've tried the new library above for a couple of sessions.
In the first session I got one read error in about 120 complete reads of the SPI flash memory.
ie 1 error in about 180,000 calls to CyU3PSpiTransmitWords().
In the second session I got 3 read errors in about 250 complete reads of the memory
ie 3 errors in about 375,000 calls to CyU3PSpiTransmitWords()
All errors occurred towards the end of a session. The new library is definitely an improvement on the one currently in SDK V1.3.4
I will be sticking with the SPI library from SDK V1.3.3 for the moment.
I have stumbled upon the same problem and my solution was to simply use the libcyu3lpp.a file from SDK 1.3.3.
I would just like to mention here my observations for anyone else who suffers from it.
I do not know the exact HW details of FX3, but from the sources it is clear that the 1.3.3 CyU3PSpiTransmitWords waits for CY_U3P_LPP_SPI_TX_DONE after each transmitted word, while 1.3.4 does it only after the whole block is sent out.
I could just extrapolate there may be somewhere an error in the CY_U3P_LPP_SPI_TX_SPACE detection and the firmware may in some cases try to write into a full fifo, while waiting for done ensures there always multiple words available in the fifo and the check for CY_U3P_LPP_SPI_TX_SPACE becomes redundant.
Difference in CyU3PSpiTransmitWords() between SDK 1.3.3 and 1.3.4:
In SDK 1.3.3:
Before a word is put into the SPI Data FIFO, the API used to wait for the FIFO to get empty.
In SDK 1.3.4:
To improve the performance of CyU3PSpiTransmitWords(), the below was done:
If there is space left(which means at-least for one word) in the FIFO, then a word is put in it without waiting for the entire FIFO to get empty.
But doing this has got some limitations.
So, in the library that I have shared with you earlier: We tried to rectify it. But it just reduces the probability of occurrence of issue.
Now, in this post, I share one more library, which reduces the issue occurrence even further. That is: After the last word is put in the FIFO, and before disabling the SPI TX, there is a provision to insert some delay (through an API CyU3PSpiSetTxFlushWaitPeriod() ).
So, what needs to be done is: Before you use SPI in your firmware, call the above API to set some delay which is in the order of uS. For your info, I have put the declaration of the function below:
So, try giving some delay and test it out.
Password for the attachment:
If you are not worried about the rate of SPI transfer (words transmitted/time), then libcyu3lpp.a from SDK 1.3.3 is good enough to go.
debug_release_versions.zip 302.5 K
thank you for the improvements, I was thinking about something similar, but at the end I've just wrote my own SPI access library based on the SDK 1.3.3 as on the SPI the reliability is most critical for us, while the speed is not. So I will not be able to test your improvements, but maybe someone else, who finds this page will.