Sharc 21061 DMA Slips

I am having a problem with multichannel DMA operation on the Sharc
21061.

I have a board with an '061 and two Dallas 2155 T1/E1 transceivers. 
The 2155s are set to E1 mode.  The '061 is set to send and receive
data using multichannel mode with DMA chaining and ping pong data
buffers.

I connect the two E1 transceivers back to back for testing.  Of
course, there are 32 slots, 8 bits per slot, and an 8 kHz frame rate. 
Both SPORTS transmit data on all 32 slots.

The problem is that after between 1 minute and 4 hours of operation,
the transmit data is no longer aligned correctly with the frame sync
pulse.  It has slipped.  In all of my experiments I have watched the
transmit data on SPORT1 and the receive data on SPORT0.  It always
slips by 8 bits, so the received data bytes are correct, they are just
in the wrong slots.  It looks like the DSP has decided at some point
to insert an extra 8 bits into the output data stream for no reason at
all.  I call this a slip.

I rented a Tektronix 7104 scope just to look at this problem.  I
thought that maybe the E1 transceivers were not putting out a
consistent clock or frame sync.  It turns out that they are.  The 7104
can trigger on pulse widths outside a given range, and even though I
had a slip, the scope did not trigger on either the clock or the frame
sync.  Also, the E1 transceiver FAS lost counters are zero, so I am
not losing E1 sync.  So it looks like a DSP problem.

When I run my code under the emulator, I can start up the code and let
it initialize the system.  I then halt the emulator, but leave the
SPORT DMA enabled.  In this configuration, I do not get any slips,
even after 16 hours of operation.

With the code running, I set a hardware breakpoint to break on data
access between 0x60 and 0xFF (this is where all of the DMA and SPORT
registers live).  I do not get any accesses to this range after the
system is set up.

I have disabled most of my application level code other than the
startup stuff, and the problem persists.  What is left running is my
operating system.  This is Precise/MQX 2.40.  All it does is sit
around and service the timer interrupt, which does involve some
context switching.  I have the source code, and context switching is
mostly a matter of stack management and saving registers.  A lot of
registers are saved, but none of them look like they have anything to
do with DMA.  If they did, I should have caught it with a hardware
breakpoint described in the previous paragraph.

So... once in a while my code is doing something to mess up the DMA
transfer and make it add an extra time slot to the outgoing data
stream.  How can the DMA be messed up without writing to the DMA
registers?

Any thoughts and opinions would be greatly appreciated.

Greg

Greg,

although I'm not familiar with your system I've seen this kind of
behaviour before on other systems and have suffered the headache
associated with it. To me, what you are describing looks like a kind
of integer/counter overflow/wraparound problem. Do you have any
counters that are incremented for each input sample (or maybe slot)
that might reach their maximum value and wrap back, therefore creating
a discontinuity? The exceptionally long period of the problem seems to
suggest something along this line.

Just my 2 cents.

--smb

> Do you have any
> counters that are incremented for each input sample (or maybe slot)
> that might reach their maximum value and wrap back, therefore creating
> a discontinuity? The exceptionally long period of the problem seems to
> suggest something along this line.
> 
> Just my 2 cents.
> 
> --smb


No, I am not counting samples or anything like that.  Once the system
is up and running, I am really just doing two things:

1.  Read 4 samples from ADC, decimate, send 1 sample to E1
2.  Read sample from E1, interpolate, send 4 samples to DAC

This is the kind of system that once it runs for 100ms correctly, I
would expect it to run forever.

Thanks for your thoughts, (and if you have any others, please don't
hesitate to post)

Greg