You are here

Adding Component Breaks DMA Transfer | Cypress Semiconductor

Adding Component Breaks DMA Transfer

Summary: 12 Replies, Latest post by cen199 on 25 Oct 2016 09:41 AM PDT
Verified Answers: 1
Last post
Log in to post new comments.
cen199's picture
User
9 posts

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:

0,1,2,3,4,5,6

Sequence after adding Quadrature Decoder component:

0,5,7,9,4,6,8

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

user_1377889's picture
User
9625 posts

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.

 

Bob

cen199's picture
User
9 posts

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

Thanks

cen199's picture
User
9 posts

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.

cen199's picture
User
9 posts

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.

user_1377889's picture
User
9625 posts

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.

 

Bob

cen199's picture
User
9 posts

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.  

Attachments: 
user_1377889's picture
User
9625 posts

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.

 

Bob

cen199's picture
User
9 posts

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.

user_1377889's picture
User
9625 posts

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.

 

Bob

cen199's picture
User
9 posts

Ok, will do. Thanks.

Log in to post new comments.