bad vme interrupt 0 or uninitialized vme interrupt - VxWorks

This is a discussion on bad vme interrupt 0 or uninitialized vme interrupt - VxWorks ; 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 ...

+ Reply to Thread
Results 1 to 8 of 8

Thread: bad vme interrupt 0 or uninitialized vme interrupt

  1. bad vme interrupt 0 or uninitialized vme interrupt

    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
    apazosm@gmail.com


  2. Re: bad vme interrupt 0 or uninitialized vme interrupt

    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!

    apazosm@gmail.com wrote:
    > 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
    > apazosm@gmail.com



  3. 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

    cxz@hy-mobile.com wrote:
    > 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!
    >
    > apazosm@gmail.com wrote:
    > > 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
    > > apazosm@gmail.com



  4. Re: bad vme interrupt 0 or uninitialized vme interrupt

    yes, it may also be a macro like,
    CACHE_PIPE_FLUSH();

    wish it will be helpful

    apazosm@gmail.com wrote:
    > 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
    >
    > cxz@hy-mobile.com wrote:
    > > 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!
    > >
    > > apazosm@gmail.com wrote:
    > > > 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
    > > > apazosm@gmail.com



  5. Re: bad vme interrupt 0 or uninitialized vme interrupt

    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.

    Thank you for your help.
    Andrés M. Pazos

    cxz@hy-mobile.com wrote:
    > yes, it may also be a macro like,
    > CACHE_PIPE_FLUSH();
    >
    > wish it will be helpful
    >
    > apazosm@gmail.com wrote:
    > > 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
    > >
    > > cxz@hy-mobile.com wrote:
    > > > 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!
    > > >
    > > > apazosm@gmail.com wrote:
    > > > > 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 happenthe
    > > > > 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
    > > > > apazosm@gmail.com



  6. Re: bad vme interrupt 0 or uninitialized vme interrupt

    Could be that the new macro functions that I am including (EIEIO, CACHE
    FLUSH), introduce a delay at the ISR that makes my system work?


    apazosm@gmail.com wrote:
    > 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.
    >
    > Thank you for your help.
    > Andrés M. Pazos
    >
    > cxz@hy-mobile.com wrote:
    > > yes, it may also be a macro like,
    > > CACHE_PIPE_FLUSH();
    > >
    > > wish it will be helpful
    > >
    > > apazosm@gmail.com wrote:
    > > > 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
    > > >
    > > > cxz@hy-mobile.com wrote:
    > > > > 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!
    > > > >
    > > > > apazosm@gmail.com wrote:
    > > > > > 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
    > > > > > apazosm@gmail.com



  7. Re: bad vme interrupt 0 or uninitialized vme interrupt

    Do you know how long to finish your code between intLock and
    intUnlock? Make it short as soon as possible!
    apazosm@gmail.com wrote:
    > Could be that the new macro functions that I am including (EIEIO, CACHE
    > FLUSH), introduce a delay at the ISR that makes my system work?
    >
    >
    > apazosm@gmail.com wrote:
    > > 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.
    > >
    > > Thank you for your help.
    > > Andrés M. Pazos
    > >
    > > cxz@hy-mobile.com wrote:
    > > > yes, it may also be a macro like,
    > > > CACHE_PIPE_FLUSH();
    > > >
    > > > wish it will be helpful
    > > >
    > > > apazosm@gmail.com wrote:
    > > > > 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
    > > > >
    > > > > cxz@hy-mobile.com wrote:
    > > > > > 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!
    > > > > >
    > > > > > apazosm@gmail.com wrote:
    > > > > > > 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
    > > > > > > apazosm@gmail.com



  8. Re: bad vme interrupt 0 or uninitialized vme interrupt

    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.


    tony wrote:
    > Do you know how long to finish your code between intLock and
    > intUnlock? Make it short as soon as possible!
    > apazosm@gmail.com wrote:
    > > Could be that the new macro functions that I am including (EIEIO, CACHE
    > > FLUSH), introduce a delay at the ISR that makes my system work?
    > >
    > >
    > > apazosm@gmail.com wrote:
    > > > 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.
    > > >
    > > > Thank you for your help.
    > > > Andrés M. Pazos
    > > >
    > > > cxz@hy-mobile.com wrote:
    > > > > yes, it may also be a macro like,
    > > > > CACHE_PIPE_FLUSH();
    > > > >
    > > > > wish it will be helpful
    > > > >
    > > > > apazosm@gmail.com wrote:
    > > > > > 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
    > > > > >
    > > > > > cxz@hy-mobile.com wrote:
    > > > > > > 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!
    > > > > > >
    > > > > > > apazosm@gmail.com wrote:
    > > > > > > > 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 0to
    > > > > > > > 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 ISRthe
    > > > > > > > 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 andread 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
    > > > > > > > apazosm@gmail.com



+ Reply to Thread