PDCA data wrap problem

Go To Last Post
8 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What would cause inbound (peripheral to internal memory) PDCA transfer data to wrap? 

 

I can't explain it.  On a UC3C2512C, I'm using the PDCA to read SPI data from an external device.  After the PDCA writes the data to a memory buffer, I see the data shifted and wrapped in that memory buffer.  All of the data I expect is contained inside the memory buffer, but the data is shifted and wrapped.  

 

For example, using an oscilloscope, I see the following on the MISO line:

 

0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 

 

and in the memory buffer I see the last three bytes wrapped:

 

0x07 0x08 0x09 0x00 0x01 0x02 0x03 0x04 0x05 0x06

 

As well, when I increase the SPI clock rate I see more wrapping.  The frequency of SPI transfers also seems to change the number of wrapped bytes.  In some cases, I can see the number of wrapped bytes toggle between X and X plus one, as if just at a threshold.  

 

Any ideas what could cause this?   

This topic has a solution.
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Have you enabled ring buffering on the PDCA channel?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks DukerX.  

 

No, ring buffering is not on.  But, it kind of acts like it is enabled.  The strange thing is that the amount of wrapping changes based on timing.  

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

And you're sure it is the PDCA channel causing this problem?

Could it be the data is ordered properly in SRAM but the readout procedure somehow get confused when the timings get tighter?

If you are using a debugger, you could add a breakpoint somewhere sensible and examine the SRAM directly in a memory view.

Looking closer at the code that writes to the PDCA registers, and the values being written to said registers could also reveal unintended behaviour.

 

I have never seen this happen in any of my projects and in one UC3C project in particular, I'm giving the memory a real workout, feeding the MACB at 50% link saturation on 100MBit, Several USARTS, the ADCIFA and the PWM controller pushing and pulling data through PDCA all the time, oh and a 6 channel 16Bit ADC dumping 250ksps++ per channel through the EBI.

 

The PDCA in UC3C has a built-in performance monitor you can configure to watch one of the 16 data channels. If you point that to the channel in question, maybe that could shed some light on what's going on.

 

There is nothing about this in the errata and I find it difficult to believe you have discovered a new "undocumented feature" in such an important module in the chip.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

DukerX, I'm sure you're right about the problem being on my end and not a hardware feature.  Historically when I have a problem like this its because of something I'm doing wrong.  :-)

 

The data is also wrapped in SRAM using the debugger.  It appears that the wrapping is real.  

 

Thanks again for the help!

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

I found my problem.  I was enabling the PDCA Rx channel before the PDCA Tx channel.  If they are both enabled at the same time everything works great.  

 

It must be that the wrapped data I was seeing was data from the prior data set, so the Rx and Tx channels were out of sync or not aligned as I expected.

 

Problem solved! 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My problem now is that I periodically see a corrupt byte of data.  Most of the time a complete transfer of data is good.  When I do find a stray/corrupted byte, the rest of the transferred data is good.  This problem happens more often when the SPI clock rate is increased.   Right now my SPI clock is running at 15MHz.

Last Edited: Fri. Sep 26, 2014 - 11:22 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Looks like at higher clock speed transfers the SPI 4 byte fifo is necessary as the PDCA cannot respond fast enough.  After I enabled the SPI MR.rxfifoen bit my problem was resolved.