I am trying to solve a problem with the handle of vme interrupts at
high speed, 1khz or more, when I am latching the position of IK320 vme
cards.

My system:
I have several VME encoder cards (heidenhain-IK320) that are latched at
1 kHz by a CPU Motorola MVME5100-2263 MPC-7410 under VxWorks 5.5.1
kernel 2.6.
They are configured at the IRQ 3 and with the interrupt vectors: C1, C2
and C3. (I also tried different interrupt configurations and happen the
same)

The problem:
When I start latching the position I receive an unintialized vme
interrupt at the group address of the cards, in this case at the C0
vector, and the cards do not answer any more.
If I include in my code the commands "eieio" and "sync" I also receive
a bad vme interrupt 0.

Detailed description:
The cards have a flag "TRANSFER MARKER" that must be set to 0 to
indicate the card that is ready to write again.
I also need to set the INTERRUPT STATUS to 0 to reset the interrupts
and be ready for the next one.
I have located that the problem is at the ISR.
1) If I reset the interrupt status at the end of the ISR the system
fails after 45 minutes aprox.
2) If I reset the interrupt status at the begining of the ISR the
system fails immediately
3) I have a partial solution that is to include a delay in the ISR so
the system seems to work well. Depending of the delay it crashes after
hours.

I also tried to include in my code the orders EIEIO, SYNC and read the
interrupt status but I didn't solve the problem

It may alse be the problem of the faster CPU speed than your bus, which
i meet last week.
You can just reflash your cache and put the cached data into RAM.

Wish it will be helpful.
Good Luck!

[email]apazosm@gmail.com[/email] wrote:[color=blue]
> I am trying to solve a problem with the handle of vme interrupts at
> high speed, 1khz or more, when I am latching the position of IK320 vme
> cards.
>
> My system:
> I have several VME encoder cards (heidenhain-IK320) that are latched at
> 1 kHz by a CPU Motorola MVME5100-2263 MPC-7410 under VxWorks 5.5.1
> kernel 2.6.
> They are configured at the IRQ 3 and with the interrupt vectors: C1, C2
> and C3. (I also tried different interrupt configurations and happen the
> same)
>
> The problem:
> When I start latching the position I receive an unintialized vme
> interrupt at the group address of the cards, in this case at the C0
> vector, and the cards do not answer any more.
> If I include in my code the commands "eieio" and "sync" I also receive
> a bad vme interrupt 0.
>
> Detailed description:
> The cards have a flag "TRANSFER MARKER" that must be set to 0 to
> indicate the card that is ready to write again.
> I also need to set the INTERRUPT STATUS to 0 to reset the interrupts
> and be ready for the next one.
> I have located that the problem is at the ISR.
> 1) If I reset the interrupt status at the end of the ISR the system
> fails after 45 minutes aprox.
> 2) If I reset the interrupt status at the begining of the ISR the
> system fails immediately
> 3) I have a partial solution that is to include a delay in the ISR so
> the system seems to work well. Depending of the delay it crashes after
> hours.
>
> I also tried to include in my code the orders EIEIO, SYNC and read the
> interrupt status but I didn't solve the problem
>
> This is the code that I am executing:
>
> void IK320Driver::interruptService_()
> {
> unsigned char lowByte;
> unsigned char highByte;
>
> //Lock the interrupts
> short key = intLock();
>
> highByte = (unsigned char) ((ik320_->interruptStatus & 0xFF00) >> 8);
> lowByte = (unsigned char) ( ik320_->interruptStatus & 0x00FF );
>
> //Clear interrupt Status
> ik320_->interruptStatus = 0; // Clear interrupt status
>
> // Check interrupt Status
> switch (highByte)
> {
> //read the data
> //reset the transfer marker
> }
>
> /Unlock the interrupts
> intUnlock(key);
>
> }
>
> I really appreciate any comment.
>
> Andrés M. Pazos
> [email]apazosm@gmail.com[/email][/color]

10-02-2007, 08:54 AM

unix

Re: bad vme interrupt 0 or uninitialized vme interrupt

Thank you for your answer, but how can I reflash my cache? is something
related whith isync?

Thank you again,
Greetings
Andrés M. Pazos

[email]cxz@hy-mobile.com[/email] wrote:[color=blue]
> It may alse be the problem of the faster CPU speed than your bus, which
> i meet last week.
> You can just reflash your cache and put the cached data into RAM.
>
> Wish it will be helpful.
> Good Luck!
>
> [email]apazosm@gmail.com[/email] wrote:[color=green]
> > I am trying to solve a problem with the handle of vme interrupts at
> > high speed, 1khz or more, when I am latching the position of IK320 vme
> > cards.
> >
> > My system:
> > I have several VME encoder cards (heidenhain-IK320) that are latched at
> > 1 kHz by a CPU Motorola MVME5100-2263 MPC-7410 under VxWorks 5.5.1
> > kernel 2.6.
> > They are configured at the IRQ 3 and with the interrupt vectors: C1, C2
> > and C3. (I also tried different interrupt configurations and happen the
> > same)
> >
> > The problem:
> > When I start latching the position I receive an unintialized vme
> > interrupt at the group address of the cards, in this case at the C0
> > vector, and the cards do not answer any more.
> > If I include in my code the commands "eieio" and "sync" I also receive
> > a bad vme interrupt 0.
> >
> > Detailed description:
> > The cards have a flag "TRANSFER MARKER" that must be set to 0 to
> > indicate the card that is ready to write again.
> > I also need to set the INTERRUPT STATUS to 0 to reset the interrupts
> > and be ready for the next one.
> > I have located that the problem is at the ISR.
> > 1) If I reset the interrupt status at the end of the ISR the system
> > fails after 45 minutes aprox.
> > 2) If I reset the interrupt status at the begining of the ISR the
> > system fails immediately
> > 3) I have a partial solution that is to include a delay in the ISR so
> > the system seems to work well. Depending of the delay it crashes after
> > hours.
> >
> > I also tried to include in my code the orders EIEIO, SYNC and read the
> > interrupt status but I didn't solve the problem
> >
> > This is the code that I am executing:
> >
> > void IK320Driver::interruptService_()
> > {
> > unsigned char lowByte;
> > unsigned char highByte;
> >
> > //Lock the interrupts
> > short key = intLock();
> >
> > highByte = (unsigned char) ((ik320_->interruptStatus & 0xFF00) >> 8);
> > lowByte = (unsigned char) ( ik320_->interruptStatus & 0x00FF );
> >
> > //Clear interrupt Status
> > ik320_->interruptStatus = 0; // Clear interrupt status
> >
> > // Check interrupt Status
> > switch (highByte)
> > {
> > //read the data
> > //reset the transfer marker
> > }
> >
> > /Unlock the interrupts
> > intUnlock(key);
> >
> > }
> >
> > I really appreciate any comment.
> >
> > Andrés M. Pazos
> > [email]apazosm@gmail.com[/email][/color][/color]

I tried the solution that you propose me (CACHE_PIPE_FLUSH) together
with an EIEIO. It had some effect because the program was working
well... but after one night running it crashed and the LCU is blocked
so I have to reboot. I saw the same effect when I included a delay at
the ISR.
I know that we are on the right direction but it is not still
completely solved.

I don't know exactly how long it takes becuase I have a basecounter but
it can't be call from the ISR and I think that I don't have my BSP
compiled to use the others hardware counters.
My ISR worked very fast but I had interrupt problems (explained in last
emails). Now I have included an EIEIO and a CACHE_FLUSH after each bus
access and it seems to work fine, because I don't have any interrupt
error message. I don't know If it is working well because it is the
right solution or because these macro calls include a delay big enough
to make my system work. I say that because my prior temporal solution
was to include a delay (aprox 20 microsecs) at the ISR and everything
worked.