7 Replies Latest reply on Mar 21, 2019 3:55 AM by jasec_826411

    SDK 1.3.4: Possible regression SPI MOSI byte dropout captured on oscilloscope.

    fefoc_3428701

      Hi

       

      After rebuilding our firmware using your 1.3.4 SDK to improve USB3 comms robustness, we are now experiencing random byte dropouts on the MOSI line, leading to frequent EEPROM read corruptions. This was not happening before the upgrade. Can you please help? Traces attached. Thanks.

       

      Fernando Fonseca

      Snr Elec Eng

      Malvern Panalytical Ltd.

        • 1. Re: SDK 1.3.4: Possible regression SPI MOSI byte dropout captured on oscilloscope.
          HemanthR_06

          Hi Fernando,

           

          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)

           

          Regards,

          Hemanth

          • 2. Re: SDK 1.3.4: Possible regression SPI MOSI byte dropout captured on oscilloscope.
            cococ_1408546

            Hi Hemanth,

             

            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() )

             

            Regards,

            Colin Cooper

            Embedded Software Engineer

             

             

             

            • 3. Re: SDK 1.3.4: Possible regression SPI MOSI byte dropout captured on oscilloscope.
              HemanthR_06

              Hi Colin,

               

              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?

               

              Regards,

              Hemanth

              • 4. Re: SDK 1.3.4: Possible regression SPI MOSI byte dropout captured on oscilloscope.
                cococ_1408546

                Hi Hemanth,

                 

                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.

                • 5. Re: SDK 1.3.4: Possible regression SPI MOSI byte dropout captured on oscilloscope.
                  jasec_826411

                  Hi Hemanth,

                  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.

                   

                  Regards,

                    Jan

                  • 6. Re: SDK 1.3.4: Possible regression SPI MOSI byte dropout captured on oscilloscope.
                    HemanthR_06

                    Hi Jan,

                     

                    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:

                    -----------------------------------------------

                    CyU3PReturnStatus_t

                    CyU3PSpiSetTxFlushWaitPeriod (

                            uint16_t delay_us)

                    -----------------------------------------------

                     

                    So, try giving some delay and test it out.

                     

                    Password for the attachment:

                    cypress

                     

                    Note:

                    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.

                     

                    Regards,

                    Hemanth.

                    • 7. Re: SDK 1.3.4: Possible regression SPI MOSI byte dropout captured on oscilloscope.
                      jasec_826411

                      Hi Hemanth,

                      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.

                       

                      Best regards,

                        Jan