Adding Component Breaks DMA Transfer

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
mare_570566
Level 2
Level 2
10 replies posted 5 replies posted 5 sign-ins

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.

0 Likes
12 Replies
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

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

0 Likes

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

0 Likes

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

   

}

   

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.

0 Likes
lock attach
Attachments are accessible only for community members.

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.

0 Likes
lock attach
Attachments are accessible only for community members.
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

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

0 Likes
lock attach
Attachments are accessible only for community members.

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.  

0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

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

0 Likes

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.

0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

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

0 Likes

Ok, will do. Thanks.

0 Likes
mare_570566
Level 2
Level 2
10 replies posted 5 replies posted 5 sign-ins

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.  

0 Likes
mare_570566
Level 2
Level 2
10 replies posted 5 replies posted 5 sign-ins

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.

0 Likes