| Electronics > Repair |
| Fluke PM6666 counter freezing after 3 seconds from turning on. |
| << < (13/27) > >> |
| coromonadalix:
@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 ?? |
| khs:
@ 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. |
| pizzigri:
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. |
| pizzigri:
--- Quote from: coromonadalix on October 11, 2020, 02:06:07 am ---@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 ?? --- End quote --- 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? |
| thinkfat:
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. |
| Navigation |
| Message Index |
| Next page |
| Previous page |