Re: [Linux-gpib-general] Agilent 82357B repeatable hard failure

[Jim H. <ji...@ov...>]

On 7/26/23 09:01, dave penkler wrote:
> Hi,
> Judging from 
> https://tomverbeure.github.io/2022/12/02/HP3478A-Multimeter-Calibration-Data-Backup-and-Battery-Replacement.html 
> it should work.
> What are you seeing on the console log ?
> /d

Hi Dave,

Thanks for getting back to me. I had seen that page.  I'm adding the 
mailing list back
to the cc.

I'm not sure if I have a bug or just subtly broken hardware.

I didn't find anything obvious in the kernel logs.
I have been slowly adding debug to the agilent_82357a driver.  The 
failure mode is a timeout
in agilent_82357a_take_control().  It is going through the process of 
writing AUX_TCS  to the
AUXCR register to set ATN and then looping the 10 times calling 
agilent_82357a_update_status()
and not finding ATN set.  It returns the -ETIMEDOUT which becomes EBUS 
by the time it reaches
the ibterm.  This is the state after I send the "W4" command with 
ibterm.  It looks like the
"W4" command works it responds with a "F" but all subsequent commands 
get the EBUS
failure.

It isn't obvious why the command being sent "W1" vs. "W4"
would cause this failure.

I have been looking for similar reports in the archives and notice the 
thread:
*[Linux-gpib-general] Agilent 82350b can't recover from read timeout? 
<https://sourceforge.net/p/linux-gpib/mailman/message/36727912/>*
https://sourceforge.net/p/linux-gpib/mailman/linux-gpib-general/thread/CAKrfojgY%2BEfzqo4e3vOEoC1vU0dEPnV_BrdDVuG1PJ%2BCHge_tw%40mail.gmail.com/#msg36730587
I see that there are workarounds in tms9914_take_control and related 
drivers.
I'm not sure if this problem would apply to the 82357B but I may try the
workaround.

I'm also thinking about getting out my logic analyzer.  I found a gpib 
cable with
flying leads already hooked.

Jim Houston