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

FYI the fix you provided made no difference. It's definitely the RHDF that
seems to unstick the ability to assert ATN. I'm not sure what other side
effects that's likely to have.

Dirk

On Mon, Jul 29, 2019 at 6:20 PM Dirk Niggemann <[email protected]>
wrote:

> 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 becauase 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