ISR falls off cliff...sometimes.

On Thursday 08 November 2007 16:51:01 you wrote:
> > But this was wrong. In fact, these are macros defined in an include
> > called async.h. I have attached it.
>
> both yahoogroups and dsprelated snip attachements completely, could you
> forward the file directly for me?

This email is going to the group and to you; attachment provided. Curiously,
I have been getting mails from yahoogroups with attachments on them.

>
> Re the ISR: keep trying to get it working (responding to PCI->DSP
> interrupts) with the single ISR code. It is fine if you remove the code
> that assigns the ISR from the minidriver and put it into your application
> code. For now there is no reason to repeatedly reassigns ISR, when testing
> PCI transfers. I think that most (0.95) of the problems is in the interrupt
> processing.
>
I have concluded, based upon the discussions on this group and on some
hardware analysis I have done, that you are correct about this, and I have
been reorganizing both my program and the mini driver accordingly.

I was able to determine that the isr provided in the minidriver was never
being invoked, hence the callback function was never being invoked, hence the
asynchronous transfers were never being synchronized. What I have now (also
attached) has my isr combined with the minidriver isr, and that isr is being
invoked both on the host to dsp interrupt and on the master transfer
completed interrupt.

When it got to the point where the master transfer interrupt was being invoked
I was able to determine that one of the minidriver changes I had originally
labeled a bug in fact wasn't and I therefore commented out a change that I
had made.

Now it is closer to working, but at one point (which I am still tracking down)
the isr "falls off the cliff" and the whole program resets and starts again
at the main routine, which results inevitably in a hang. I suspect this
program reset is coming about in some fashion due to an incorrect removal of
a task and/or an incorrect freeing of a channel, which is then supposed to be
reallocated. This is also sometimes hanging the PCI bus.

> I had to do something else, so I have not done much on the analysis, but
> the next thing to do is to check how the semaphore is working. It holds the
> application until after the large composite transaction to host has been
> completed - or that was the plan. I still need to check it, where it is
> signaled and where it is tested.

I have changed this semaphore to be dynamically created, since that now seems
to work (it didn't before). I was defining it statically.
>
> Rgds,
>
> Andrew Start a New Thread