-
#50 Reply
Posted by
FransW
on 08 Oct, 2020 10:58
-
-
#51 Reply
Posted by
khs
on 08 Oct, 2020 11:59
-
Is there an interrupt line from the GPIB board to the CPU??
-
#52 Reply
Posted by
pizzigri
on 08 Oct, 2020 14:08
-
Is there an interrupt line from the GPIB board to the CPU??
No, there are only three lines going to the IEC (GPIB) Bus: 5MHz clock, SCL and SDA. Power is supplied via an unregulated 12V, which an LDO onboard the GPIB PCB then converts to 5V reg.
What is interesting, is that the PM6666 has the whole PSU always on, transformer, rectifiers, big levelling capacitors etc; what the power switch does is only to connect the already powered on unregulated rail to the LDOs and the rest of the circuit. So, since the GPIB is powered thru the UNREG rail, it is always on, even if the rest of the counter is "off".
-
#53 Reply
Posted by
khs
on 08 Oct, 2020 18:03
-
If you take a look at IC105 (on page 7 of the service manual) the option signal of the GPIB board (BU102 on page 15) is connected to the interrupt input of IC105.
Is there a way to check (or cut) the option wire?
-
#54 Reply
Posted by
pizzigri
on 08 Oct, 2020 20:31
-
Yes I see it, I can monitor the line using the BU102 connector. It’s what I used for I2C anyway since it replicates all lines for diagnosing purposes
-
#55 Reply
Posted by
khs
on 08 Oct, 2020 21:10
-
I would be interesting to see I²C clock/data and the option signal (BU102) together - from your working counter and from your not working counter.
Additional you may check the I²C data signal with an oscilloscope and compare the voltages to to your 'working' counter.
There are two pullups for I²C clock / data: R147/R148. You may check the values and solder points.
Again just my 2 cents..
-
#56 Reply
Posted by
pizzigri
on 09 Oct, 2020 07:27
-
KHS,
this evening I'll try to check it out. I do have a DSO, I'll connect it this evening and also the logic analizer and see what comes out! Thanks for the heads up.
-
#57 Reply
Posted by
pizzigri
on 09 Oct, 2020 16:02
-
So I checked the pullup resistors they are basically almost spot on at 1.48K (both of them) however I'm measuring in circuit.
Iterrupts, I treid with the Saleae logic analizer, there's absolutely no traffic that I can see in the Option line, unless I am mistaken.
And also, I have to rectify a statement: it is true that there's always unreg power to the GPIB connectr, however the gnd ref is controlled by the main switch so the board does get powered on when the power switch is pressed. However, and I did test this, using one of the two GND lines and unreg +V, it is possible to keep something always on inside the meter - i.e. an OCXO osc, that then is always ready when the whole meter is turned on.
I am struggling with the brand new Siglent SDS1202X-E, which does have I2C decoding and a lot of other things but I have to learn that too! Uff. I could not see the signal levels yet. However, as I said, no traffic on OPTION interrupt.Surely I'm doing somethng wrong? It HAS to have some traffic.
-
-
is there a configuration pin, something who tells there is an gpib card installed ?? id pin ?
an tensy wheeny little thing ? something so stupid to make it work in this 6666 ??
I havent seen the schematic, was it posted ?
-
#59 Reply
Posted by
khs
on 10 Oct, 2020 20:59
-
However, as I said, no traffic on OPTION interrupt.Surely I'm doing somethng wrong? It HAS to have some traffic.
If there is no traffic I would take my next two cents and:
1) Make an adapter to connect pin by pin from the mainboard to the GPIB board.
2) Isolate all connections - and check the counter.
- the counter should run.
3) Connect GND and check the counter.
4) Conenct the positive power supply and check the counter.
If there is a problem check the power supply.
5) Connect I²C clock and check the counter.
The counter should work.
6) connect I²C Data and check the counter.
7) connect OPTION and check the counter.
Then maybe we know more..
-
-
@khs that would be a good start sequence ? what bothers me is the gpib cards are all fine on another model ? an enumeration command ? something the 6666 doesnt catch after 3 secs
Could it be a given delay to acknowledge the card and if its not reporting back okay, the counter get stuck ? or a non gpib enabled firmware is running ?? and you have to find an dump of an gpib enabled /working fw dump ??
-
#61 Reply
Posted by
khs
on 11 Oct, 2020 18:58
-
@ coromonadalix:
You are right. All is possible.
Because we know more or less nothing - and additional the counter is not on our desks - my appoach is to suggest some test as simple as possible.
If we have a running counter at step 6 or maybe at step 7 it could be possible there is a firmware problem.
Before step 5 without any connection to the I²C bus it's possible maybe there are other reasons than firmware problems.
-
#62 Reply
Posted by
pizzigri
on 12 Oct, 2020 09:44
-
Small update, took KHS suggestions and done a Dupont extension/adapter.
Wire by wire, everything works until I connect I2C lines, scl and sda.
Power is fine.
Clock is fine.
Option line (pin 9) does not make a difference. Crashes either it is not connected or if it is, so long that SDA/SCL are also connected.
I dont think there is something wrong with the option line, i.e. since there is no reply from it, the machine crashes - because downscale card and TXCO options are also connected to this line and they work correctly. If I remove the 1.3ghz option, the meter does not allow me to select C channel, as it should be, and works well.
So I suppose it has to do with I2C.
-
#63 Reply
Posted by
pizzigri
on 12 Oct, 2020 10:04
-
@khs that would be a good start sequence ? what bothers me is the gpib cards are all fine on another model ? an enumeration command ? something the 6666 doesnt catch after 3 secs
Could it be a given delay to acknowledge the card and if its not reporting back okay, the counter get stuck ? or a non gpib enabled firmware is running ?? and you have to find an dump of an gpib enabled /working fw dump ??
No way to recover a fw dump, the memory of the cpu is mask rom, and no way to burn a rom....
the cpu is correct for the meter, the last line of the CPU markings include the meter designation, and the last two digits of the series ( i.e. for the PM66xx the xx is engraved on the chip)
The CPU is correctly engraved “66”. So if it is a problem with the fw, it is a problem with the Mask ROM.
But, I never heard of Mask ROM going bad, is that an actual thing?
-
#64 Reply
Posted by
thinkfat
on 12 Oct, 2020 10:21
-
Did you notice in your LA traces of the I2C bus that the bus gets stuck? SDA and SCL are both fixed low, they're not returning to idle state. Something on the bus is blocking it, physically, while being talked to. The bus is then "busy" and the program in the counter is probably waiting forever for the condition to clear.
PS: I went back and looked through the spreadsheet you posted with the decoded I2C communication. It gets stuck trying to talk to something with the address 0x10. So I guess whatever has this address in the system is what's causing the hang.
PS2: an interesting test to make: while the counter hangs, disconnect the SDA/SCL lines from the GPIB interface. Does it return to normal?
PS3: Another thing to check: Does the 5MHz signal actually reach IC2 on the GPIB card? I'm guessing that the I2C state machine is driven by SCL so it reacts to its own slave address (0x10), but then if the 5MHz is missing, the rest of the slave I2C processing maybe doesn't happen and the bus is stuck in (or after) the ACK. An I2C slave may pull SCL low if it needs more time for processing. Maybe this is what is hardwired in IC2 and when it doesn't get its main clock, it will never release this SDA/SCL low condition.
-
#65 Reply
Posted by
pizzigri
on 12 Oct, 2020 12:44
-
Thinkfat,
I did as suggested! Yes, that is exactly what happens. I started the meter with the GPIB board connected and waited until the thing locked up. Then, i disconnected the SDA line, still locked up. Then the SCL, and it unlocked, all this obviously with the meter powered. I am looking at the manual excerpts that FransW is posting, and the "Addr 10" is indeed the GPIB...
-
#66 Reply
Posted by
thinkfat
on 12 Oct, 2020 12:51
-
What I can see is that the OCR didn't really increase the utility of the scanned document :-)
-
#67 Reply
Posted by
pizzigri
on 12 Oct, 2020 12:56
-
Yes, haha!
In any case better than nothing at all...
In the meantime I connected my scope and got a 5mhz signal, quite jittery but that could be imperfect probe technique.
-
#68 Reply
Posted by
pizzigri
on 12 Oct, 2020 13:45
-
Going to say something really stupid here but... could it be a ground related issue?
I see dispersion on the chassis, and the oooold Schaffner filter is still in place - the ones that exploded...
Suggestions?
-
#69 Reply
Posted by
thinkfat
on 12 Oct, 2020 14:03
-
Ground is probably not a major issue, but the 5 MHz signal doesn't look too good. Does the documentation say anything about it? 2.54V peak is too low for a CMOS input (which I assume IC2 has). A CMOS logic high level starts at 3.5V. For TTL it would be OK. Is there anything specified about maximum rise time?
EDIT: I saw you use a 1X probe. That might get you into a bandwidth issue. Switch the probe to 10X and make sure it's properly compensated. Then redo the measurement.
-
#70 Reply
Posted by
FransW
on 12 Oct, 2020 16:17
-
Anything I can do?
Missing manual info?
Frans
-
-
@Fransw
Have you scanned the schematics ?? i did not see them if you posted the files here ? or i have missed them
thks for your work
-
#72 Reply
Posted by
pizzigri
on 12 Oct, 2020 18:46
-
OK, so redone the measure with 10x probe. The result is 385mV (forgot to set the scope to 10x) so that makes 3.85V. Therefore good. Bandwidth of the probes at 1x is 6MHz, so I thought that they would work at 5Mhz....
Measuring 72V AC dispersion as well across the chassis. Should I float it? Or add a 1K resistor to gnd pin on power lead?
Today a new thing actually happened: the meter did not freeze with the GPIB connected. It happened once, but I did not notice it until I turned it off - that in fact the GPIB was connected to it - and then it did not do it again!
I have a mighty headache. Today I cant do anything more, I will put myself back into it tomorrow!
I believe that we are getting somewhere anyhow. I apologize, I am just a hobbyist however I'm learning more trying to figure out this than in years at school.
Thank you for your help guys
PS Frans, are there details on the I2C protocol in addition to what you already posted?
-
#73 Reply
Posted by
khs
on 12 Oct, 2020 19:00
-
Thinkfat,
Then, i disconnected the SDA line, still locked up. Then the SCL, and it unlocked, all this obviously with the meter powered. I am looking at the manual excerpts that FransW is posting, and the "Addr 10" is indeed the GPIB...
From my understanding the counter should run with the I²C SCL line connected, because the I²C SCL is an output from the CPU.
Is there a difference of the SCL signal from the CPU connected to GPIB and the SCL signal not connected to GPIB?
-
-
yep the "SCL" clock should'nt be affected unless something is dragging it down ?
How do you measure 72vac ? between the frame and the scope ground ?? for a scope it would be best to add an isolation transformer for safety reasons, unless you have a ground problem
![Huh? ???](https://www.eevblog.com/forum/Smileys/default/xhuh.gif.pagespeed.ic.6Nvt7O8a11.png)
Check if your screw(s) hole(s) are not transfering ground between the main board and the gpib board Ex passing thru a strud, an "pem" "punched stud in the metal" inserted in the metal etc ...