Fwd: Agilent 82350b can't recover from read timeout?

Hi Frank,

I'd traced it down to ibcac (in sys/ibcac.c) and  tms9914_take_control()
in tms9914_aux.c myself- it skips the TCS because the board is not
addressed to listen and goes straight to the TCA which fails with ATN
unasserted.

The weird thing is i managed to unwedge the TCA by sending  write_byte(
priv, AUX_RHDF, AUXCR );  just before it- (in a misunderstanding of how
holdoffs in read actually work, I think).

Regards,

Dirk



On Mon, Jul 29, 2019 at 5:09 PM Frank Mori Hess <[email protected]> wrote:

> On Mon, Jul 29, 2019 at 8:17 AM Frank Mori Hess <[email protected]> wrote:
> >
> > On Sun, Jul 28, 2019 at 3:22 PM Dirk Niggemann <[email protected]>
> wrote:
> > >
> > > Hi,
> > >
> > > I have a strange difference in behaviour between the Agilent 82357a
> and the Agilent 82350b cards in linux-gpib-4.2.0 running on ubuntu 16.04 on
> a 32-bit kernel  4.4.0-157-generic.
> > >
> > > Sending an invalid command ('ID' instead of '*IDN?') to a specific
> device (HP7673 on ID 8) results in a bus lockup. On the 82357a this can be
> cleared using ibclr() but on the 82350b the lockup can only be cleared by
> reinitialising the board with gpib_config.
> > >
> > > Any other command aborts immediately with iberr set to 14  EBUS until
> the board is reinitialised.
> > >
> > > The EBUS error is directly translated ETIMEDOUT error from the ibcmd
> ioctl,
> > >
> > > This error occurs immediately, even if the timeout is set to 10s, so
> it's almost like the timer can't  successfully restart after a timeout.
> > >
> > > I can't figure why nothing clears this error on the 82350b.
> >
> >
> > It's probably a bug in the tms9914 module.  My guess the chip is
> > raising an error interrupt (HR_ERR) to try to indicate a data byte got
> > discarded without being read.  Hmm actually try adding the change I
> > just added in svn commit 1821.  It looks like the tms9914 command
> > coded needed to clear the bus error state.
>
> Hmm, actually from what you said it the timeout must be coming when
> the board tries to assert the ATN line.  So in the kernel drivers,
> ibcmd is calling ibcac is calling tms9914_take_control which is timing
> out.  It makes sense the synchronous attempt to take control would
> fail, but it should be falling back to asynchronous which should not
> fail (but apparently it is).
>
> --
> Frank
>
>
> _______________________________________________
> Linux-gpib-general mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/linux-gpib-general
>

_______________________________________________
Linux-gpib-general mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-gpib-general