12 Replies Latest reply on Oct 25, 2016 9:41 AM by mare_570566

    Adding Component Breaks DMA Transfer


      I'm still getting familiar with PSoC 5LP.  Hopefully this is a simple question that can be answered with a link to some document I should have read.


      The project has a DMA transfer to an SPI Master component.  This is a series of 8 bit writes on TX FIFO not full.  The transfer normally works fine.


      The problem starts when a Quadrature Decoder component is added.  I also noticed the same problem with SPI slave, but will refer to the Quadrature decoder for this example.  After the Quadrature Decoder is added, the DMA transfer bytes appear to be out of order.  This is a result of adding the component, with no manual C code changes.


      For example, a byte buffer with consecutive 0 through 15 was set up as the source.  The following transfers were observed:


      Good sequence:




      Sequence after adding Quadrature Decoder component:




      I don't know how these components could interact.  Any ideas on where to start investigating will be appreciated.

        • 1. Re: Adding Component Breaks DMA Transfer

          Best procedure would be when somebody else is able to reproduce that issue. So can you please post your complete project, so that we all can have a look at all of your settings. To do so, use
          Creator->File->Create Workspace Bundle (minimal)
          and attach the resulting file.





          • 2. Re: Adding Component Breaks DMA Transfer

            I can't post this project.  I will try to reproduce the problem with a more basic project that does not have proprietary code.



            • 3. Re: Adding Component Breaks DMA Transfer

              There are several lines like this in the SPIM header:


              #define SPIM_INT_ON_TX_EMPTY    ((uint8) (0u   << SPIM_STS_TX_FIFO_EMPTY_SHIFT))


              These should be shifting 1u.  I don't use the interrupts, so this shouldn't affect my original problem.




              I can get proper operation with a direct copy loop:


              for(i=0; i<10; i++)


              while(0u == (SPIM_TX_STATUS_REG & SPIM_STS_TX_FIFO_NOT_FULL)) { }
              CY_SET_REG8(SPIM_TXDATA_PTR, SCOUTtxPacket.rawdata[i]);




              SCOUTtxPacket appears properly packed in memory window.  I'm back to thinking this is a DMA problem.  


              SPI slave gave timing warnings when trying to make a loopback test program.  So still no basic test to upload.

              • 4. Re: Adding Component Breaks DMA Transfer

                A simplified test is attached.  There is a timing violation on the SPI slave, but I continued anyway since it still appears to work for test purposes.  


                TESTLENGTH bytes of data are copied to the SPI master and looped back to the SPI slave.  


                The test transmit runs from a timer interrupt every 300us.


                If TESTLENGTH is set to 5, the program works as expected.  


                If TESTLENGTH is set to 7, the bytes are out of order and 6 bytes are sent.


                I can see the data on the oscilloscope, so I don't think any receive problems are fooling me.  Writing with SPIM_2_WriteTxData() instead of DMA gives a correct loopback.

                • 5. Re: Adding Component Breaks DMA Transfer

                  Project runs flawlessly on a CY8CKIT-059


                  Changes made:

                  • Changed the cyapicallbacks.h to suit your needs.
                  • Declared rxptr as volatile
                  • Changed project settings->compiler->optimization to "none" for easier debugging.
                  • Changed target device.
                  • Changed clock settings (no xtal, IMO at 70MHz)

                  Setting a breakpoint at the error detection.


                  As long as the program is not disturbed (stopped) it runs without generating an error.





                  • 6. Re: Adding Component Breaks DMA Transfer

                    Thanks for checking this out.  I downloaded your archive, changed the target device back, and it ran without error here.  


                    I returned to my original example and changed PLL_OUT to 70Mhz.  It began working.  A scopeshot is attached of the output.  The output at 70Mhz is shown with the faded traces.  The 80Mhz output is the brighter overlaid traces.  The output at 80Mhz is missing a byte and has 2 out of order or corrupted bytes.


                    At this point it appears that CY8C5287AXI-LP095 is not fully functional at 80Mhz.  The test project will only run properly up to PLL_OUT of 76Mhz.  My crystal is running a little fast, so in reality this is 78.08Mhz.  The datasheet specifies the part to 80.01Mhz.  

                    • 7. Re: Adding Component Breaks DMA Transfer

                      Look at SPI datasheet, AC characteristics. The SPI is overclocked in the current configuration, > 8MHz and Highspeed mode not activated. Interesting that it does run at all.





                      • 8. Re: Adding Component Breaks DMA Transfer

                        Valid point, but unrelated.  I changed the SPI clock to 1 MHz, and could not get it to work with PLL_OUT above 74MHz.  


                        I'll believe the DMA to Datapath FIFO connections can't take the speed unless I can find a better explanation.




                        *Edit* Upon further review, SPI was not overclocked at 10Mhz.  8 bit fSCLK is maximum 9MHz.  This makes incoming clock fCLOCK 18MHz maximum.

                        • 9. Re: Adding Component Breaks DMA Transfer

                          When something is not running as the specs promise, I would suggest to have Cypress informed. Can you please create a support case (at top of this page -> Design Support -> Create a Support Case and give them all the information (project archives, link to this thread) needed. Would be nice when you keep us informed of any results/answers from Cypress.





                          • 10. Re: Adding Component Breaks DMA Transfer

                            Ok, will do. Thanks.

                            • 11. Re: Adding Component Breaks DMA Transfer

                              An update in case anyone else is interested in this problem:


                              I purchased a CY8CKIT-059 just to have the same board as tech support.  The problem can be reproduced on the 059 board.  I have a slightly improved version of the test program that can catch all the errors with a breakpoint.  The program runs properly at 70Mhz, but not 79Mhz.  


                              Tech support has not come up with a solution yet.  

                              • 12. Re: Adding Component Breaks DMA Transfer

                                Solution found.  BUS_CLK and the SPI component clock are not the same.  Because the DMA was level triggered, it seems that it was transferring too many bytes before the component could clear the FIFO not full flag.  Changing the interrupt flag to FIFO empty rising edge made the program work reliably.  The FIFO isn't being used effectively with this setup, but the DMA is fast enough to keep SPI transfer continuous, so it isn't a problem.