DSPRelated.com
Forums
   Forums    More Forums    adsp  

Hardware dma problem

Started by drmike8888 ●March 14, 2003
I have an A/D connected to a SHARC 21061 EZ-KIT. It is connected
via the DMAG2 and DMAR2 lines, so there's no address decoding.

I use the TIMEXP line to start an A/D conversion. The part is a
12 bit 1 MHz converter, so the TIMEXP line fires a conversion once
every 1 or 2 microseconds (timing on that doesn't seem to matter
to this problem).

The DMAR2 line comes out the A/D's INT signal to tell the 21061 that
a conversion is complete. The DMAG2 line is connected to the RD line
of the A/D. I just set up the DMA controller to read 16/32 packed
data into block 1 of the 21061 ram space.

Most of the time it works, but every now and then it "locks up".
The DMAG2 line goes low and *stays* low. Writing 0x2000 (flush bit)
do the DMAC6 doesn't clear the line back high. ONLY a hardware reset
will clear it.

I noticed that the INT signal goes high _immediatly_ when the DMAG2
line goes low, so DMAR2 is cleared instantly (within 10 nanoseconds
usually). The manual says the DMA signals are supposed to be
asyncronous, but I'm beginning to think that's not so.

Has anyone a clue what the problem might be? Anybody else ever
seen anything like this on the SHARC DMA controller?

Thanks for any hints!!!




Reply by Noffke, Pat ●March 14, 20032003-03-14
We found a similar problem with the 21065. I spoke with ADI and they
weren't able to reproduce the problem with their tests, and we didn't want
to send them our hardware. Our workaround was to flush any pending DMA
requests by starting a DMA transfer, poll DMASTAT for completion, and repeat
this for a short time (enough to flush 1 or so requests that the DMA
controller may think it received). If there were no queued up requests,
then just abort the flush operation after the time limit, and begin your DMA
transfer as normal.

Fortunately we had enough time between our hardware interrupt and when we
needed to start the transfer, that we were able to use this workaround. If
you don't have sufficient time, you may need to try something else.

Perhaps the DMAR2 line (in both your platform and ours) was seeing glitches
that caused the DMA controller to queue up a request. Then once the DMA is
enabled, it tries to satisfy all those requests until it's caught up. If
you can't flush as above, maybe you can try looking for such glitches.

Good luck,
Pat

> -----Original Message-----
> From: drmike8888 [mailto:]
> Sent: Friday, March 14, 2003 11:11 AM
> To:
> Subject: [adsp] Hardware dma problem > I have an A/D connected to a SHARC 21061 EZ-KIT. It is connected
> via the DMAG2 and DMAR2 lines, so there's no address decoding.
>
> I use the TIMEXP line to start an A/D conversion. The part is a
> 12 bit 1 MHz converter, so the TIMEXP line fires a conversion once
> every 1 or 2 microseconds (timing on that doesn't seem to matter
> to this problem).
>
> The DMAR2 line comes out the A/D's INT signal to tell the 21061 that
> a conversion is complete. The DMAG2 line is connected to the RD line
> of the A/D. I just set up the DMA controller to read 16/32 packed
> data into block 1 of the 21061 ram space.
>
> Most of the time it works, but every now and then it "locks up".
> The DMAG2 line goes low and *stays* low. Writing 0x2000 (flush bit)
> do the DMAC6 doesn't clear the line back high. ONLY a hardware reset
> will clear it.
>
> I noticed that the INT signal goes high _immediatly_ when the DMAG2
> line goes low, so DMAR2 is cleared instantly (within 10 nanoseconds
> usually). The manual says the DMA signals are supposed to be
> asyncronous, but I'm beginning to think that's not so.
>
> Has anyone a clue what the problem might be? Anybody else ever
> seen anything like this on the SHARC DMA controller?
>
> Thanks for any hints!!! >
>
> _____________________________________
> Note: If you do a simple "reply" with your email client, only
> the author of this message will receive your answer. You
> need to do a "reply all" if you want your answer to be
> distributed to the entire group.
>
> _____________________________________
> About this discussion group:
>
> To Join: Send an email to
>
> To Post: Send an email to
>
> To Leave: Send an email to
>
> Archives: http://groups.yahoo.com/group/adsp
>
> Other Groups: http://www.dsprelated.com/groups.php3 > ">http://docs.yahoo.com/info/terms/


Reply by Mike Rosing ●March 17, 20032003-03-17
On Fri, 14 Mar 2003, Noffke, Pat wrote:

> We found a similar problem with the 21065. I spoke with ADI and they
> weren't able to reproduce the problem with their tests, and we didn't want
> to send them our hardware. Our workaround was to flush any pending DMA
> requests by starting a DMA transfer, poll DMASTAT for completion, and repeat
> this for a short time (enough to flush 1 or so requests that the DMA
> controller may think it received). If there were no queued up requests,
> then just abort the flush operation after the time limit, and begin your DMA
> transfer as normal.
>
> Fortunately we had enough time between our hardware interrupt and when we
> needed to start the transfer, that we were able to use this workaround. If
> you don't have sufficient time, you may need to try something else.
>
> Perhaps the DMAR2 line (in both your platform and ours) was seeing glitches
> that caused the DMA controller to queue up a request. Then once the DMA is
> enabled, it tries to satisfy all those requests until it's caught up. If
> you can't flush as above, maybe you can try looking for such glitches.
>
> Good luck,
> Pat

THANKS! That you've actually seen it makes me feel better.

There may well be glitches. I'm going to try to stretch out the DMAR2
because all the specs ADI show it going high well before DMA grant, or
well after. In my case, it's almost simultaneous (less than 10 nanosec
anyway).

I'm using the timer to force the dma requests, I suppose I can see if none
come in after 2 TIMEXP then I might as well flush. I did try a flush with
my debugger and it didn't work, but the processor isn't running either.

Thanks for the reply, very much appreciated!

Mike Rosing




Reply by drmike8888 ●March 17, 20032003-03-17

Well, I tried to lengthen the DMA request, but it did not
change the problem. I added a 100 pf cap to the DMAR2 line
and this really helped stretch out the signal by a full clock.
So what I saw on the logic analyzer was DMAR2 *longer* than
DMAG2!!

According to the manual, if DMARx is held low in the cycle before
DMAGx goes low, DMAGx is supposed to add a wait state. This never
happens.

So it looks like "handshake mode" does not work as advertised.
I'm going to add some glue logic and switch over to "paced master
mode", which should allow me to put in 2 or 3 wait states on the
RD signal. DMAG won't be used then, I just have to use one of
the MSx lines ored with RD for the data transfer.

Thanks for the note Pat! Your reply was very much appreciated.

Patience, persistence, truth,
Dr. mike
(aka Mike Rosing)

Reply by Noffke, Pat ●March 18, 20032003-03-18
I don't see why lengthening DMAR would fix the problem. Or
were you thinking that adding the cap would potentially
remove any glitches?

I've attached the emails sent between ADI and myself back
when I was dealing with this problem. Maybe those will be of help.

Good luck,
Pat

P.S. I tried sending to your email shown below, but it was
non-deliverable.

>
>
> > -----Original Message-----
> > From: drmike8888 [mailto:]
> > Sent: Monday, March 17, 2003 9:06 AM
> > To:
> > Subject: [adsp] Re: Hardware dma problem
> >
> >
> >
> > Well, I tried to lengthen the DMA request, but it did not
> > change the problem. I added a 100 pf cap to the DMAR2 line
> > and this really helped stretch out the signal by a full clock.
> > So what I saw on the logic analyzer was DMAR2 *longer* than
> > DMAG2!!
> >
> > According to the manual, if DMARx is held low in the cycle before
> > DMAGx goes low, DMAGx is supposed to add a wait state. This never
> > happens.
> >
> > So it looks like "handshake mode" does not work as advertised.
> > I'm going to add some glue logic and switch over to "paced master
> > mode", which should allow me to put in 2 or 3 wait states on the
> > RD signal. DMAG won't be used then, I just have to use one of
> > the MSx lines ored with RD for the data transfer.
> >
> > Thanks for the note Pat! Your reply was very much appreciated.
> >
> > Patience, persistence, truth,
> > Dr. mike
> > (aka Mike Rosing)
> >
> >
> > _____________________________________
> > Note: If you do a simple "reply" with your email client, only
> > the author of this message will receive your answer. You
> > need to do a "reply all" if you want your answer to be
> > distributed to the entire group.
> >
> > _____________________________________
> > About this discussion group:
> >
> > To Join: Send an email to
> >
> > To Post: Send an email to
> >
> > To Leave: Send an email to
> >
> > Archives: http://groups.yahoo.com/group/adsp
> >
> > Other Groups: http://www.dsprelated.com/groups.php3
> >
> >
> > ">http://docs.yahoo.com/info/terms/


From:  "Support, DSP" <>
Date:  Tue Nov 30, 1999  6:04 pm
Subject:  RE: Anomaly regarding external port DMA, ATTN: Maggie Nakhla
To:  Patrick Noffke <pjnoffke@buddha>

Hi Patrick,

I tried again to duplicate the problem that you're seeing, but we couldn't
do
it. I tried a non-multiple of 8 writes in Master Mode DMA followed by a
switch
to external handshake mode and we never saw the DMAG line going low.
Are you still seeing the problem? Do you always see it? Have you narrowed
down
the conditions by which it occurs?

Regards,
Maggie Nakhla
DSP Applications Engineer
Email:
PHONE: 1-800-AnalogD
FAX: 781-461-3010
FTP: FTP.analog.com
WEB: WWW.analog.com
DSP EZ-Answers: http://www.analog.com/dsp/EZ/index.html

> ----------
> From: Patrick Noffke[SMTP:]
> Reply To: Patrick Noffke
> Sent: Monday, November 29, 1999 10:43 AM
> To: Support, DSP
> Subject: Re: Anomaly regarding external port DMA, ATTN: Maggie
Nakhla
>
> Hi Maggie,
>
> Thanks for the update.
>
> Yes, we're using the 21065L. We've seen the problem on both Rev 0.2 and
> Rev 0.3.
>
> If you still cannot produce the problem today, then I'll try to get you
> some more information about our setup and the experiments we've done.
>
> *************************************************
> Patrick Noffke
> QTI Color Registration Systems
> Sussex, WI
> *************************************************
>
> ----- Original Message -----
> From: Support, DSP <>
> To: Patrick Noffke <pjnoffke@buddha>
> Sent: Tuesday, November 23, 1999 5:06 PM
> Subject: RE: Anomaly regarding external port DMA, ATTN: Maggie Nakhla > > Hello Patrick,
> >
> > Just wanted to let you know that as of today I was not able to
> duplicate your problem. We are still working on the issue, and I
will
be able to give
> you a more complete description of our results on Monday. As of
now,
> though, we do not see the DMAG line go low.
> >
> > You were using the ADSP-21065L, right?
> >
> > Regards,
> > Maggie
> >


From:  "Support, DSP" <>
Date:  Tue Nov 23, 1999  11:06 pm
Subject:  RE: Anomaly regarding external port DMA, ATTN: Maggie Nakhla
To:  Patrick Noffke <pjnoffke@buddha>

Hello Patrick,

Just wanted to let you know that as of today I was not able to duplicate
your
problem. We are still working on the issue, and I will be able to give you a
more complete description of our results on Monday. As of now, though, we
do
not see the DMAG line go low.

You were using the ADSP-21065L, right?

Regards,
Maggie > ----------
> From: Patrick Noffke[SMTP:]
> Reply To: Patrick Noffke
> Sent: Thursday, November 18, 1999 3:16 PM
> To: Support, DSP
> Subject: Re: Anomaly regarding external port DMA, ATTN: Maggie
Nakhla
>
> Maggie,
>
> Could you please provide me with a little more detail? I am very
> interested to know if you have been able to produce the problem. And if
you
> have, I
> would like to know if you have any more insight into what causes the
problem?
> I explained some conditions that put the DMA controller into the errant
> state, but we now have reason to believe that other conditions may cause
the
> same
> effect.
>
> I can't elaborate because we don't know exactly what those conditions
> are yet, but I can tell you that we tried to avoid the problem by not
using
> master mode DMA on that channel (this required a board change).
Apparently,
> this
> was not sufficient, as we're still occasionally seeing the DMAG go low
> immediately after the DMA is enabled. If you haven't been able to produce
the
> problem
> with the code suggestions I gave earlier, then perhaps we're both looking
in
> the
> wrong place.
>
> In any case, if you have more questions about our board or software,
> please let
> me know.
>
> Sincerely,
>
> *************************************************
> Patrick Noffke
> QTI Color Registration Systems
> Sussex, WI
> (414) 566-7825
> *************************************************
> ----- Original Message -----
> From: Support, DSP <>
> To: Patrick Noffke <pjnoffke@buddha>
> Sent: Wednesday, November 10, 1999 10:05 AM
> Subject: RE: Anomaly regarding external port DMA, ATTN: Maggie Nakhla > > Hi Patrick,
> >
> > We are still working on the issue. I'll let you know when I have
> further
> > information.
> >
> > Regards,
> > Maggie Nakhla
> > DSP Applications Engineer
> > Email:
> > PHONE: 1-800-AnalogD
> > FAX: 781-461-3010
> > FTP: FTP.analog.com
> > WEB: WWW.analog.com
> > DSP EZ-Answers: http://www.analog.com/dsp/EZ/index.html
> >
> >
> > > ----------
> > > From: Patrick Noffke[SMTP:]
> > > Reply To: Patrick Noffke
> > > Sent: Tuesday, November 09, 1999 9:49 AM
> > > To: dsp support
> > > Subject: Re: Anomaly regarding external port DMA, ATTN: Maggie
> Nakhla
> > >
> > > Hi Maggie,
> > >
> > > Could you please tell me the status of your testing? Have you been
> able
> > > to
> > > duplicate the problem?
> > >
> > > Regards,
> > >
> > > *************************************************
> > > Patrick Noffke
> > > QTI Color Registration Systems
> > > Sussex, WI
> > > *************************************************
> > >
> > > ----- Original Message -----
> > > From: Support, DSP <>
> > > To: Patrick Noffke <pjnoffke@buddha>
> > > Sent: Monday, November 01, 1999 3:29 PM
> > > Subject: RE: Anomaly regarding external port DMA, ATTN: Maggie
> Nakhla
> > >
> > >
> > > > Hi Patrick,
> > > >
> > > > Our group's scope was being calibrated. Just got it back and I
> will
> > > try it out
> > > > to see if I can duplicate your issue. I'll let you know what I
> find
> > > out ASAP.
> > > >
> > > > Regards,
> > > > Maggie Nakhla
> > > > DSP Applications Engineer
> > > > Email:
> > > > PHONE: 1-800-AnalogD
> > > > FAX: 781-461-3010
> > > > FTP: FTP.analog.com
> > > > WEB: WWW.analog.com
> > > > DSP EZ-Answers: http://www.analog.com/dsp/EZ/index.html
> > > >
> > > >
> > >
> > >
> >

From:  "Support, DSP" <>
Date:  Mon Nov 22, 1999  6:55 pm
Subject:  RE: Anomaly regarding external port DMA, ATTN: Maggie Nakhla
To:  Patrick Noffke <pjnoffke@buddha>

Hi Patrick,

I have spent the last week working with a colleague to manipulate one of the
ADSP-21065L EZ-Lab boards to be able to test what you are seeing. We will
get a
chance to try duplicating it either this afternoon or tomorrow and I'll let
you
know of the outcome by Wednesday (hopefully).

Regards,
Maggie Nakhla
DSP Applications Engineer
Email:
PHONE: 1-800-AnalogD
FAX: 781-461-3010
FTP: FTP.analog.com
WEB: WWW.analog.com
DSP EZ-Answers: http://www.analog.com/dsp/EZ/index.html > ----------
> From: Patrick Noffke[SMTP:]
> Reply To: Patrick Noffke
> Sent: Thursday, November 18, 1999 3:16 PM
> To: Support, DSP
> Subject: Re: Anomaly regarding external port DMA, ATTN: Maggie
Nakhla
>
> Maggie,
>
> Could you please provide me with a little more detail? I am very
> interested to know if you have been able to produce the problem. And if
you
> have, I
> would like to know if you have any more insight into what causes the
problem?
> I explained some conditions that put the DMA controller into the errant
> state, but we now have reason to believe that other conditions may cause
the
> same
> effect.
>
> I can't elaborate because we don't know exactly what those conditions
> are yet, but I can tell you that we tried to avoid the problem by not
using
> master mode DMA on that channel (this required a board change).
Apparently,
> this
> was not sufficient, as we're still occasionally seeing the DMAG go low
> immediately after the DMA is enabled. If you haven't been able to produce
the
> problem
> with the code suggestions I gave earlier, then perhaps we're both looking
in
> the
> wrong place.
>
> In any case, if you have more questions about our board or software,
> please let
> me know.
>
> Sincerely,
>
> *************************************************
> Patrick Noffke
> QTI Color Registration Systems
> Sussex, WI
> (414) 566-7825
> *************************************************
> ----- Original Message -----
> From: Support, DSP <>
> To: Patrick Noffke <pjnoffke@buddha>
> Sent: Wednesday, November 10, 1999 10:05 AM
> Subject: RE: Anomaly regarding external port DMA, ATTN: Maggie Nakhla > > Hi Patrick,
> >
> > We are still working on the issue. I'll let you know when I have
> further
> > information.
> >
> > Regards,
> > Maggie Nakhla
> > DSP Applications Engineer
> > Email:
> > PHONE: 1-800-AnalogD
> > FAX: 781-461-3010
> > FTP: FTP.analog.com
> > WEB: WWW.analog.com
> > DSP EZ-Answers: http://www.analog.com/dsp/EZ/index.html
> >
> >
> > > ----------
> > > From: Patrick Noffke[SMTP:]
> > > Reply To: Patrick Noffke
> > > Sent: Tuesday, November 09, 1999 9:49 AM
> > > To: dsp support
> > > Subject: Re: Anomaly regarding external port DMA, ATTN: Maggie
> Nakhla
> > >
> > > Hi Maggie,
> > >
> > > Could you please tell me the status of your testing? Have you been
> able
> > > to
> > > duplicate the problem?
> > >
> > > Regards,
> > >
> > > *************************************************
> > > Patrick Noffke
> > > QTI Color Registration Systems
> > > Sussex, WI
> > > *************************************************
> > >
> > > ----- Original Message -----
> > > From: Support, DSP <>
> > > To: Patrick Noffke <pjnoffke@buddha>
> > > Sent: Monday, November 01, 1999 3:29 PM
> > > Subject: RE: Anomaly regarding external port DMA, ATTN: Maggie
> Nakhla
> > >
> > >
> > > > Hi Patrick,
> > > >
> > > > Our group's scope was being calibrated. Just got it back and I
> will
> > > try it out
> > > > to see if I can duplicate your issue. I'll let you know what I
> find
> > > out ASAP.
> > > >
> > > > Regards,
> > > > Maggie Nakhla
> > > > DSP Applications Engineer
> > > > Email:
> > > > PHONE: 1-800-AnalogD
> > > > FAX: 781-461-3010
> > > > FTP: FTP.analog.com
> > > > WEB: WWW.analog.com
> > > > DSP EZ-Answers: http://www.analog.com/dsp/EZ/index.html
> > > >
> > > >
> > >
> > >
> >

From:  "Support, DSP" <>
Date:  Wed Nov 10, 1999  4:05 pm
Subject:  RE: Anomaly regarding external port DMA, ATTN: Maggie Nakhla
To:  Patrick Noffke <pjnoffke@buddha>

Hi Patrick,

We are still working on the issue. I'll let you know when I have further
information.

Regards,
Maggie Nakhla
DSP Applications Engineer
Email:
PHONE: 1-800-AnalogD
FAX: 781-461-3010
FTP: FTP.analog.com
WEB: WWW.analog.com
DSP EZ-Answers: http://www.analog.com/dsp/EZ/index.html > ----------
> From: Patrick Noffke[SMTP:]
> Reply To: Patrick Noffke
> Sent: Tuesday, November 09, 1999 9:49 AM
> To: dsp support
> Subject: Re: Anomaly regarding external port DMA, ATTN: Maggie
Nakhla
>
> Hi Maggie,
>
> Could you please tell me the status of your testing? Have you been able
> to
> duplicate the problem?
>
> Regards,
>
> *************************************************
> Patrick Noffke
> QTI Color Registration Systems
> Sussex, WI
> *************************************************
>
> ----- Original Message -----
> From: Support, DSP <>
> To: Patrick Noffke <pjnoffke@buddha>
> Sent: Monday, November 01, 1999 3:29 PM
> Subject: RE: Anomaly regarding external port DMA, ATTN: Maggie Nakhla > > Hi Patrick,
> >
> > Our group's scope was being calibrated. Just got it back and I will
> try it out
> > to see if I can duplicate your issue. I'll let you know what I find
> out ASAP.
> >
> > Regards,
> > Maggie Nakhla
> > DSP Applications Engineer
> > Email:
> > PHONE: 1-800-AnalogD
> > FAX: 781-461-3010
> > FTP: FTP.analog.com
> > WEB: WWW.analog.com
> > DSP EZ-Answers: http://www.analog.com/dsp/EZ/index.html
> >
> >


From:  "Support, DSP" <>
Date:  Mon Nov 1, 1999  9:29 pm
Subject:  RE: Anomaly regarding external port DMA, ATTN: Maggie Nakhla
To:  Patrick Noffke <pjnoffke@buddha>

Hi Patrick,

Our group's scope was being calibrated. Just got it back and I will try it
out
to see if I can duplicate your issue. I'll let you know what I find out
ASAP.

Regards,
Maggie Nakhla
DSP Applications Engineer
Email:
PHONE: 1-800-AnalogD
FAX: 781-461-3010
FTP: FTP.analog.com
WEB: WWW.analog.com
DSP EZ-Answers: http://www.analog.com/dsp/EZ/index.html > ----------
> From: Patrick Noffke[SMTP:]
> Reply To: Patrick Noffke
> Sent: Monday, October 25, 1999 5:58 PM
> To: dsp support
> Subject: Re: Anomaly regarding external port DMA, ATTN: Maggie
Nakhla
>
> Hi Maggie,
>
> > Hello Patrick,
> >
> > Just wanted to get back to you with a few more suggestions for you to
> try
> out..
> >
> > 3. Provide me with a little bit more detail on the failure..i.e.,
> what happens > exactly? You mentioned in one of your previous email
messages
> that the
> DMA controller goes into a 'problematic state.' What exactly happens?
> Pleaseprovide us with a bit more detail on the failure..
>
> As I stated in my last email (sent on 10/21), you should see the DMAG go
> low immediately after the DMA is enabled. Simply perform one dma read in
> master mode (you can poll DMASTAT to see when it has completed), and after

> that, perform one read in external handshake mode, again, polling DMASTAT
to
> detect completion. If you have no hardware to generate the DMA requests,
then
>
> the program will be stuck in the polling loop. That is okay. It still
> illustrates the problem. The grant will go low as soon as the dma is
enabled,
> and
> it stays low as long as dma is enabled. Use DMAC1=0x201 for master mode,
and
> DMAC1=0x1401 for the handshake mode.
>
> Now, if you first perform 8 (or a multiple of 8) dma reads in master
> mode, then in external handshake mode, the grant will not go low until a
> request is
> detected (this is the expected operation). So, again, if you have no
> hardware generating requests, the program will be stuck in the loop
polling
> DMASTAT, but this time, the grant will stay high.
>
> Pat

From:  "Support, DSP" <>
Date:  Mon Oct 25, 1999  10:48 pm
Subject:  RE: Anomaly regarding external port DMA, ATTN: Maggie Nakhla
To:  Patrick Noffke <>

Hello Patrick,

Just wanted to get back to you with a few more suggestions for you to try
out..

1. Have you examined the DMAR line with a scope? Specifically, DMAR should
be
high and remain high for the duration of the master mode DMA..it should not
change values at during this transfer. This is because DMA requests can be
pipelined, so if that happens when you switch to external handshake mode
there
could be some extra DMA requests pending. After the Master Mode DMA fully
completes, then the external device can request the DMA using the DMA
request
line.

2. Have you tried polling for the DMA completion by using interrupts? Try
doing that instead of polling the DMASTAT register and let me know if that
makes
a difference.

3. Provide me with a little bit more detail on the failure..i.e., what
happens
exactly? You mentioned in one of your previous email messages that the DMA
controller goes into a 'problematic state.' What exactly happens? Please
provide us with a bit more detail on the failure..

Thanks and regards,
Maggie Nakhla
DSP Applications Engineer
Email:
PHONE: 1-800-AnalogD
FAX: 781-461-3010
FTP: FTP.analog.com
WEB: WWW.analog.com
DSP EZ-Answers: http://www.analog.com/dsp/EZ/index.html > ----------
> From: Patrick Noffke[SMTP:]
> Reply To: Patrick Noffke
> Sent: Wednesday, October 20, 1999 9:18 AM
> To:
> Subject: Re: Anomaly regarding external port DMA, ATTN: Maggie
Nakhla
>
> Hi Maggie,
>
> We are using rev 0.2 of the chip. We have two boards, and have been
> able to see the problem on both of these boards. If you want, I can see
if I
> can
> get some source code to you that we used to test the problem. The code
has
> some
> parts specific to our hardware, but at least that way, you can see how we
> produced the problem. I think you may not even need special hardware to
see
> the
> problem. All you should need to look at is the DMAG after some software
> trigger
> (we used one of the I/O Port flags). Although the hardware to generate
the
> DMAR
> pulses is helpful to clearly illustrate the problem.
>
> Pat
>
> ----- Original Message -----
> From: Support, DSP <>
> To: Patrick Noffke <>
> Sent: Tuesday, October 19, 1999 3:58 PM
> Subject: RE: Anomaly regarding external port DMA > Hello Patrick,
Thanks for your email. I consulted with one of my colleagues on
this
> issue,and we have not previously encountered the problem that you are
seeing.
>
> We have never seen the chip operate in this manner. Which rev of the
> ADSP-21065L are you using? Do you see this problem happening on only one
> board, or on
> multiple boards? Do you have any other 21065L's that you can test it out.
As
> I mentioned, we haven't seen this problem before. What I'm going to do is
> consult with one of the senior apps engineers tomorrow morning...I'm
> going to disucuss the possibility of duplicating the problem, and I will
also
> discuss suggestions that you can try out. I'll get back to you as soon as
we
> talk tomorrow morning.
>
> In the meantime, if there are any other details concerning this issue,
> please pass them along.
> >
> > Thanks and regards,
> > Maggie Nakhla
> > DSP Applications Engineer
> > Email:
> > PHONE: 1-800-AnalogD
> > FAX: 781-461-3010
> > FTP: FTP.analog.com
> > WEB: WWW.analog.com
> > DSP EZ-Answers: http://www.analog.com/dsp/EZ/index.html
> >


From:  "Support, DSP" <>
Date:  Wed Oct 20, 1999  5:22 pm
Subject:  RE: Anomaly regarding external port DMA, ATTN: Maggie Nakhla
To:  Patrick Noffke <>

Hi Patrick,

Thanks for your email. Before you send over code, maybe you could provide
me
with some more details on your system..

In particular, we need to know a few more details on the Master mode DMA --
are
you waiting for the master mode DMA to complete before switching to external
handshake mode? If so, how are you verifying that the master mode DMA has
completed -- are you checking the DMA status bits (in the DMA Channel Status
Register -- See page E-36 and E-39 of the SHARC User's Manual). Are you
generating an interrupt upon completion of that DMA?
Are both of the DMA's occurring on the same channel? You mention that you
are
flushing the DMA FIFO in between the two DMA operations -- one thing to
remember is that you should not flush the DMA channel when it is active --
it
should only be used when the DMA channel is not active (again, refer to page
E-36 of the SHARC User's Manual). Use of the FLSH bit when the channel is
active may cause unexpected results.

Again, the operation of external handshake mode DMA should in no way be
affected
by the number of reads in master mode DMA...we need a few more specific
details
on both DMA transfers.

Hopefully we can determine the cause of the issue..

Regards,
Maggie Nakhla
DSP Applications Engineer
Email:
PHONE: 1-800-AnalogD
FAX: 781-461-3010
FTP: FTP.analog.com
WEB: WWW.analog.com
DSP EZ-Answers: http://www.analog.com/dsp/EZ/index.html
> ----------
> From: Patrick Noffke[SMTP:]
> Reply To: Patrick Noffke
> Sent: Wednesday, October 20, 1999 9:18 AM
> To:
> Subject: Re: Anomaly regarding external port DMA, ATTN: Maggie
Nakhla
>
> Hi Maggie,
>
> We are using rev 0.2 of the chip. We have two boards, and have been
> able to see the problem on both of these boards. If you want, I can see
if I
> can
> get some source code to you that we used to test the problem. The code
has
> some
> parts specific to our hardware, but at least that way, you can see how we
> produced the problem. I think you may not even need special hardware to
see
> the
> problem. All you should need to look at is the DMAG after some software
> trigger
> (we used one of the I/O Port flags). Although the hardware to generate
the
> DMAR
> pulses is helpful to clearly illustrate the problem.
>
> Pat
>
> ----- Original Message -----
> From: Support, DSP <>
> To: Patrick Noffke <>
> Sent: Tuesday, October 19, 1999 3:58 PM
> Subject: RE: Anomaly regarding external port DMA > > Hello Patrick,
> >
> > Thanks for your email. I consulted with one of my colleagues on this
> issue,
> and
> > we have not previously encountered the problem that you are seeing.
> We have
> > never seen the chip operate in this manner. Which rev of the
> ADSP-21065L are
> > you using? Do you see this problem happening on only one board, or on
> multiple
> > boards? Do you have any other 21065L's that you can test it out.
> >
> > As I mentioned, we haven't seen this problem before. What I'm going
> to do is
> > consult with one of the senior apps engineers tomorrow morning...I'm
> going to
> > disucuss the possibility of duplicating the problem, and I will also
> discuss
> > suggestions that you can try out. I'll get back to you as soon as we
> talk
> > tomorrow morning.
> >
> > In the meantime, if there are any other details concerning this issue,
> please
> > pass them along.
> >
> > Thanks and regards,
> > Maggie Nakhla
> > DSP Applications Engineer
> > Email:
> > PHONE: 1-800-AnalogD
> > FAX: 781-461-3010
> > FTP: FTP.analog.com
> > WEB: WWW.analog.com
> > DSP EZ-Answers: http://www.analog.com/dsp/EZ/index.html
> >


From:  "Support, DSP" <>
Date:  Wed Oct 20, 1999  5:01 pm
Subject:  RE: [Fwd: DMA over BMS (21065L, rev0.2)]
To:  Patrick Noffke <>

Hello Patrick,

In regards to your email message below...the reason that you need to set the
Address bin A23 instead of A24 is so that the correct number of wait states
is
set. You must use A23 and not A24, there was a mistake in the original
documentation stating that you have to set bit A23. If you set bit 24, the
number of wait states is not being properly set, and while the system may
work
fine (under room temperature), it may not work under different
circumstances.
To be absolutely sure that the correct number of wait states are being set,
you
must set A23.

Regards,
Maggie Nakhla
DSP Applications Engineer
Email:
PHONE: 1-800-AnalogD
FAX: 781-461-3010
FTP: FTP.analog.com
WEB: WWW.analog.com
DSP EZ-Answers: http://www.analog.com/dsp/EZ/index.html > ----------
> From: Patrick Noffke[SMTP:]
> Reply To: Patrick Noffke
> Sent: Friday, October 15, 1999 3:22 PM
> To:
> Subject: [Fwd: DMA over BMS (21065L, rev0.2)]
>
> Previously (7/8/99), I sent the attached email to dsp.support. Today I
> noticed that you have changed the anomaly list to indicate that bit A23
> must be set to generate the proper number of wait states. Could you
> please tell me what testing was performed to indicate A23 should be set
> instead of A24? And as I stated in my email of 7/8, we were able to
> learn that setting any of bits 17-26 in EIEPx was sufficient to produce
> the correct number of wait states. Was anyone at ADI able to duplicate
> this behavior, and if so, is there a reason to only use bit 23, instead
> of any bit from 17-26?
>
> I look forward to your response.
>
> Sincerely,
> Patrick Noffke
>
> [ Attachment 1.2 Type: MESSAGE/RFC822][ Forwarded message displayed
> below ]
>
> From: Patrick Noffke <>
> Subject: DMA over BMS (21065L, rev0.2)
> Organization: Quad/Tech, International
>
> A colleague of mine performed a test to verify the documented anomaly
> that address bit 24 must be set to generate the correct number of wait
> states when BSO is set. He determined that, as long as any of bits
> 17-26 were set in the EIEPx register, the number of wait states was as
> configured in the RBWM and RBWS fields of the WAIT register. This
> corresponds to an address range of 0x00020000 to 0x07FFFFFF. Using any
> address within this range works okay. And bits 27-31 are don't cares
> for this test. If bits 17-26 are all zero, there were zero wait states
> if the HIDMA bit was clear in the WAIT register, and one wait state if
> HIDMA was set.
>
> Hope this information helps. If you have any questions, please email
> me.
>
> Best Regards,
> Patrick Noffke > [ End of Forwarded Message 1 ]
>


From:  "Support, DSP" <>
Date:  Tue Oct 19, 1999  8:58 pm
Subject:  RE: Anomaly regarding external port DMA
To:  Patrick Noffke <>

Hello Patrick,

Thanks for your email. I consulted with one of my colleagues on this issue,
and
we have not previously encountered the problem that you are seeing. We have
never seen the chip operate in this manner. Which rev of the ADSP-21065L
are
you using? Do you see this problem happening on only one board, or on
multiple
boards? Do you have any other 21065L's that you can test it out.

As I mentioned, we haven't seen this problem before. What I'm going to do
is
consult with one of the senior apps engineers tomorrow morning...I'm going
to
disucuss the possibility of duplicating the problem, and I will also discuss
suggestions that you can try out. I'll get back to you as soon as we talk
tomorrow morning.

In the meantime, if there are any other details concerning this issue,
please
pass them along.

Thanks and regards,
Maggie Nakhla
DSP Applications Engineer
Email:
PHONE: 1-800-AnalogD
FAX: 781-461-3010
FTP: FTP.analog.com
WEB: WWW.analog.com
DSP EZ-Answers: http://www.analog.com/dsp/EZ/index.html > ----------
> From: Patrick Noffke[SMTP:]
> Reply To: Patrick Noffke
> Sent: Friday, October 15, 1999 4:01 PM
> To:
> Subject: Anomaly regarding external port DMA
>
> Attached are two posts I just sent to the comp.dsp newsgroup. I thought
> I would also send them to you to see if you are aware of this problem
> and might know of a good work-around.
>
> To summarize the following posts, we believe we've detected a problem
> with the DMA controller. When performing DMA reads in master mode
> (MASTER=1, HSHAKE=0, EXTERN=0), if we perform a non-multiple of 8 reads
> from external memory to internal memory, the DMA controller is left in a
> problematic state. If we then read in external handshake mode, the DMAG
> line will get asserted about one cycle after the DMA is enabled, rather
> than waiting for the first DMAR (and yes, we are flushing the DMA FIFO
> prior to performing this DMA). DMAG will remain asserted until shortly
> after the first DMAR is detected by the controller. After that, it
> responds to each DMAR as long as the DMA is enabled.
>
> But if we perform a multiple of 8 reads while in master mode, external
> handshake mode works as documented.
>
> If you have seen this behavior before, could you please recommend a
> work-around. If not, please keep me updated as to whether or not you
> can duplicate the problem. If you need more information, please don't
> hesitate to email me.
>
> Sincerely,
>
> *************************************************
> Patrick Noffke
> QTI Color Registration Systems
> Sussex, WI
> *************************************************
>
> [ Attachment 1.3 Type: MESSAGE/RFC822][ Forwarded message displayed
> below ]
>
> Date: Fri, 15 Oct 1999 10:52:29 -0500
> From: Patrick Noffke <>
> Subject: 21065 external port DMA
> Organization: Quad/Graphics,Inc.
>
> Hi folks,
>
> I'm having a problem using the DMA controller to transfer image data
> between
> an external device and external memory (external handshake mode). It
> seems
> like the DMAG line is going low when it shouldn't be. Just before I
> begin
> the DMA, I write a 1 to the FLSH bit in the DMAC register. This should
> clear any pending DMA requests. There really shouldn't be any requests
> that
> aren't handled, but just in case there's a problem with our external
> logic
> in generating the requests, I'm flushing the DMA FIFO. So after
> flushing, I
> set up the DMA controller registers and finally enable the DMA. On the
> scope I can see that the DMAG is going low about 30 ns after the DMA is
> enabled. I can also see that there are no requests happening around
> this
> time. The first DMAR pulse comes 10s of us after the DMA is enabled.
>
> This unwanted DMAG assertion doesn't happen all the time. Occasionally,
> it
> does what we expect. It seems to change after I call some other
> functions
> that perform DMA between internal and external memory. After calling
> those
> functions, I perform another image DMA, and the DMAG remains deasserted
> until three cycles after the first request (as expected). But this
> behavior
> seems to "toggle." Sometimes after I call those functions, it behaves,
> other times, it doesn't. It's pretty random. Also, after I start the
> processor, there are some other uses of the DMA controller before I get
> to
> my DMA image test. These uses also involve DMA between internal and
> external memory. (Basically it's a boot kernel loading the app code
> from
> flash memory.) And if I try to DMA an image first thing after the app
> code
> gets loaded, the DMAG is getting asserted when it shouldn't (i.e. right
> after the DMA is enabled).
>
> Another clue is that our ACK pin is untied. There are internal pullups
> on
> this pin, so we should be able to leave it unconnected unless our
> external
> device needs it to hold off the DMAG. But apparently the DSP isn't
> doing
> what we expect. It may be related to this or something else we haven't
> cons
> idered. If anyone has experienced a similar problem, would you please
> explain what's happening?
>
> Thanks in advance.
> --
>
> *************************************************
> Patrick Noffke
> QTI Color Registration Systems
> Sussex, WI
> ************************************************* > [ End of Forwarded Message 1 ]
> [ Attachment 1.1 Type: MESSAGE/RFC822][ Forwarded message displayed
> below ]
>
> Date: Fri, 15 Oct 1999 14:58:07 -0500
> From: Patrick Noffke <>
> Subject: Re: 21065 external port DMA
> Organization: Quad/Graphics,Inc.
>
> I have more information. The problem is related to the performing DMA
> reads
> in master mode (in DMACx, MASTER=1, HSHAKE=0, EXTERN=0). If we perform
> a
> multiple of 8 DMA reads in master mode prior to performing the image
> grab
> (external handshake mode), then the DMA controller behaves as expected.
> That is, the DMAG line remains deasserted until the first DMAR is
> received.
> But any non-multiple of 8 in master mode will leave the controller in
> the
> messed up state, where, in external handshake mode (MASTER=0, HSHAKE=1,
> EXTERN=1), the DMAG is asserted right after the DMA is enabled.
>
> Has anyone seen this behavior before? We're trying to figure out a way
> to
> reset the DMA controller. Flushing the EPBx FIFOs doesn't do it. But
> when
> you reset the chip, the controller is in the proper state. It would be
> nice
> if there was a bit to reset the DMA controller. But I know of no such
> bit.
> One work-around is to make sure we're always reading (and probably
> writing
> as well) multiples of 8-bytes while in master mode. But this is not an
> ideal work-around.
>
> Any insights will be greatly appreciated.
>
> --
>
> *************************************************
> Patrick Noffke
> QTI Color Registration Systems
> Sussex, WI
> ************************************************* > [ End of Forwarded Message 1 ]
>
Reply by Mike Rosing ●March 19, 20032003-03-19
On Tue, 18 Mar 2003, Noffke, Pat wrote:

> I don't see why lengthening DMAR would fix the problem. Or
> were you thinking that adding the cap would potentially
> remove any glitches?
>
> I've attached the emails sent between ADI and myself back
> when I was dealing with this problem. Maybe those will be of help.
>
> Good luck,
> Pat

Thanks Pat! I was thinking the cap would remove the glitches as well as
extend the DMAR so I'd get an extra wait state on the DMAG. It didn't
work.

So I tried to go to paced master mode. The bus still locked up, but with
RD strobe and MS0 low. When I attached my logic analyzer to the the
exp_clk line, all the problems went away!! I took the one probe off, and
it locked up. So I've got some very subtle bus problems - I need much
better buffering of the lines.

But I punted :-) I set up the IRQ0 to get the DMA request instead, wrote
a 4 line assembler routine that fits in the vector space to read the A/D
and it works. It isn't as finessed or clean as DMA, but at least it
works!

I'm going to re-design my prototype some day. For now, I need to get some
data from the real world. But it sure looks like the DMAR and DMAG lines
on the EZKIT need to be buffered on the board - the exp_clk line isn't
really anything to do with them as far as I can see. Pretty weird problem
though, and I can't go around with my logic analyzer attached to
everything!

> P.S. I tried sending to your email shown below, but it was
> non-deliverable.

That's the right address. Send me a test,
their server may have been off line the hour you tried.

Mike Rosing



You might also like... (promoted content)
Register EARLY and Save - DSP for Wireless Communications
Register EARLY and Save - DSP for Wireless Communications
Register EARLY and Save - DSP for Wireless Communications