Author Topic: Fluke 8846A repair shenanigans.  (Read 8976 times)

0 Members and 1 Guest are viewing this topic.

Online Johnny10

  • Frequent Contributor
  • **
  • Posts: 740
  • Country: us
Re: Fluke 8846A repair shenanigans.
« Reply #50 on: October 08, 2018, 11:00:38 pm »
Tin, you changed Outguard FPGA correct?

Tektronix TDS7104, DMM4050, HP 3561A, HP 35665, Tek 2465A, HP8903B, DSA602A, Tek 7854, 7834, HP3457A, Tek 575, 576, 577 Curve Tracers, Datron 4000, Datron 4000A, uTracer, HP5335A, EIP534B 20GHz Frequency Counter, TrueTime Rubidium, Sencore LC102, Tek TG506, TG501, SG503, HP 8568B
 

Offline TiN

  • Super Contributor
  • ***
  • Posts: 4206
  • Country: us
  • xDevs.com/live - 24/7 lab feed
    • xDevs.com
Re: Fluke 8846A repair shenanigans.
« Reply #51 on: October 08, 2018, 11:24:20 pm »
Yes.
YouTube | Metrology IRC Chat room | Live-cam | Share T&M documentation? Upload! No MB limit, firmwares, photos.
 

Online Johnny10

  • Frequent Contributor
  • **
  • Posts: 740
  • Country: us
Re: Fluke 8846A repair shenanigans.
« Reply #52 on: October 08, 2018, 11:55:00 pm »
On my unit the Inguard is not responding.

I have a functioning Outguard.
But no readings on display...
Removing the shields from the phototransistors reveals  "XC6115 series  high-precision, low current consumption voltage detectors with watchdog. The series consist of a reference voltage source, delay circuit, comparator and output driver".
Which is what triggers my error after a few seconds delay. I can see the pattern on the oscilloscope.

Outguard waiting for a signal, then resetting after time delay, coinciding with the error message appearing on the display.
« Last Edit: October 09, 2018, 04:08:52 am by Johnny10 »
Tektronix TDS7104, DMM4050, HP 3561A, HP 35665, Tek 2465A, HP8903B, DSA602A, Tek 7854, 7834, HP3457A, Tek 575, 576, 577 Curve Tracers, Datron 4000, Datron 4000A, uTracer, HP5335A, EIP534B 20GHz Frequency Counter, TrueTime Rubidium, Sencore LC102, Tek TG506, TG501, SG503, HP 8568B
 
The following users thanked this post: TiN, analogRF

Offline TiN

  • Super Contributor
  • ***
  • Posts: 4206
  • Country: us
  • xDevs.com/live - 24/7 lab feed
    • xDevs.com
Re: Fluke 8846A repair shenanigans.
« Reply #53 on: October 09, 2018, 04:16:37 am »
Johnny10, slow down, or you will get me wasting time on this 8846 again.  :-DD

On serious note - good find.  I think reversing schematics for isolation interface would be rather easy.
YouTube | Metrology IRC Chat room | Live-cam | Share T&M documentation? Upload! No MB limit, firmwares, photos.
 

Offline picburner

  • Frequent Contributor
  • **
  • Posts: 272
  • Country: it
Re: Fluke 8846A repair shenanigans.
« Reply #54 on: October 09, 2018, 06:51:31 am »
Quote
Removing the shields from the phototransistors reveals  "XC6115 series  high-precision, low current consumption voltage detectors with watchdog.

To me U54 & U63 look like AD8601ARTZ op-amp.
In fact a phototransistor pin is connected to the -in input of the op-amp and this makes sense.
What would it do to connect to the wd terminal of an XC6115??
 

Online Johnny10

  • Frequent Contributor
  • **
  • Posts: 740
  • Country: us
Re: Fluke 8846A repair shenanigans.
« Reply #55 on: October 09, 2018, 12:15:18 pm »
I am certainly not an expert on SMD markings since I have been wrong before.

SMD part marked AAA 5 pins SOT-25.

I used  SMD-Codes from 2007

« Last Edit: October 09, 2018, 01:04:35 pm by Johnny10 »
Tektronix TDS7104, DMM4050, HP 3561A, HP 35665, Tek 2465A, HP8903B, DSA602A, Tek 7854, 7834, HP3457A, Tek 575, 576, 577 Curve Tracers, Datron 4000, Datron 4000A, uTracer, HP5335A, EIP534B 20GHz Frequency Counter, TrueTime Rubidium, Sencore LC102, Tek TG506, TG501, SG503, HP 8568B
 

Offline picburner

  • Frequent Contributor
  • **
  • Posts: 272
  • Country: it
Re: Fluke 8846A repair shenanigans.
« Reply #56 on: October 09, 2018, 01:23:35 pm »
The smd codes are difficult to interpret and often generate confusion because the same code can correspond to many different devices.
I don't have this DMM and then I can't make measurements but to amplify the signal of a phototransistor I would use a hi-speed op-amp not a
voltage detector with watchdog ;)
 

Offline Miti

  • Frequent Contributor
  • **
  • Posts: 870
  • Country: ca
Re: Fluke 8846A repair shenanigans.
« Reply #57 on: October 17, 2018, 02:39:42 am »
Hi Tin,

My 8845A had a dying IR LED but it popped an error, I don't remember which error. I replaced it with a regular IR LED from an old TV remote and it works well for about 2 years now. Spray cold those LEDs, replace them. It's worth a try.
That big spark at power up was by design!
 

Offline TiN

  • Super Contributor
  • ***
  • Posts: 4206
  • Country: us
  • xDevs.com/live - 24/7 lab feed
    • xDevs.com
Re: Fluke 8846A repair shenanigans.
« Reply #58 on: October 17, 2018, 04:37:24 am »
Hi Tin,
My 8845A had a dying IR LED but it popped an error..

IR led was second thing I swapped (first one was check and confirmed good, also recap all power supply circuits). Didn't help.
YouTube | Metrology IRC Chat room | Live-cam | Share T&M documentation? Upload! No MB limit, firmwares, photos.
 

Online Johnny10

  • Frequent Contributor
  • **
  • Posts: 740
  • Country: us
Re: Fluke 8846A repair shenanigans.
« Reply #59 on: October 20, 2018, 11:14:03 pm »
OK, More testing validates picburner

Pin 1 Signal Out
Pin 4 Input
Pin 5 V+  3.43V

on the AAA 5 pin IC  AD8601ARTZ
« Last Edit: October 21, 2018, 02:00:39 am by Johnny10 »
Tektronix TDS7104, DMM4050, HP 3561A, HP 35665, Tek 2465A, HP8903B, DSA602A, Tek 7854, 7834, HP3457A, Tek 575, 576, 577 Curve Tracers, Datron 4000, Datron 4000A, uTracer, HP5335A, EIP534B 20GHz Frequency Counter, TrueTime Rubidium, Sencore LC102, Tek TG506, TG501, SG503, HP 8568B
 

Offline massivephoton

  • Contributor
  • Posts: 24
  • Country: br
Re: Fluke 8846A repair shenanigans.
« Reply #60 on: October 31, 2018, 02:03:04 pm »
LAN port however does not work, cannot connect to it either in static IP mode, or DHCP. DHCP does not get any IP address from network. Perhaps LAN Phy is killed?

Too bad ethernet didn't work even while the unit worked. Telnet on port 23 asks for login/psw, which is disclosed in plaintext in the available 2.x firmware files. Once inside, there's uCLinux basic commands, ftp server, some scripts for comm configuration as well as default settings stored.

Symptoms:
(...)
5.All connect to LAN, and activity pulses can be seen at two second intervals. One time I saw one of them connect to my Asus router and get an IP address. I was unable to get it to repeat this though...

Did you ever manage to get an IP again? You could try to login on port 23 and inspect. Also, there are chances that the firmware update (or downgrade?) tool works from this point.

My unit runs the latest firmware listed in Xdevs.com, and I'm having a minor issue that if I break the telnet connection sometimes it no longer accepts SCPI connections on port 3490, but keeps alive at port 23. I know I shoudn't be using wi-fi with instruments, but hey, it's pretty good when it works. Already tried to reboot each network devices in the path between the notebook and the DMM, but didn't work. I'd like to telnet connect on port 23 and restart the telnet process to regain SCPI control on port 3490, but when I kill the only telnetd process listed on `ps aux` command, the connection on port 23 is interrupted. I can reconnect on port 23, but  it doesn't restore telnet connection on port 3490. Also, if I run a reboot command, it restarts the outguard processor, the DMM keeps measuring and updating the display, but still no connection on telnet on port 3490.
I can try to replicate tests or copy files from the instrument if needed. You may try to convince me, but I just don't feel inclined to open the unit, since it's still under warranty. Sorry, I couldn't resist and turned it on instead of tearing it apart. :-(

Hope your meters return from the dead soon!
Happy halloween!
- J'ai vu une maison de cent mille francs.
- Comme c'est joli!
 

Offline SilverSolder

  • Super Contributor
  • ***
  • Posts: 3456
  • Country: 00
Re: Fluke 8846A repair shenanigans.
« Reply #61 on: November 02, 2018, 02:03:18 am »




What is the purpose of the aluminum box over the input connections on the 8508A in the picture?  In later pictures, it (or a clone) appears on the calibrator as well.
 

Offline massivephoton

  • Contributor
  • Posts: 24
  • Country: br
Re: Fluke 8846A repair shenanigans.
« Reply #62 on: November 06, 2018, 02:58:01 am »
Had a little more time to play on the weekend.

All power on my 8846 is fine, nothing cooking or shorted. It is not relevant to the "init screen hang" issue, because meter should boot even with inguard section completely unpowered (removed transformer cable from inguard).

Probably, but I wouldn't be so sure on v1 firmware.

Quote
Jwalling, yes, there is no life on optos from outguard to inguard. There is slow square wave on pair from inguard to outguard (perhaps just heartbeat signal).

The measurement app is ca. 1MB in size, /usr/bin/zfp. Killing this process halts measurements, freezing the display. I'd expect the opto communication to halt too. Zfp app is called at the end of /etc/rc script:

Code: [Select]
#!/bin/sh
#
# system startup.

# expand and mount the ramdisk
#/bin/dd if=/usr/bin/ramfs.img of=/dev/ram0
/bin/expand /ramfs.img /dev/ram0
/bin/mount -t ext2 /dev/ram0 /tmp -n
/bin/expand /ramfs.img /dev/ram1
/bin/mount -t ext2 /dev/ram1 /var -n

# mount proc file system
/bin/mount -t proc proc /proc -n

# mount sysfs
/bin/mount -t sysfs sysfs /sys -n

# mount the jffs2 R/W file system
# /bin/mount -t jffs2 /dev/mtdblock2 /usr -n

# mount the romfs RO (SAFE) partition
/bin/mount -t romfs /dev/mtdblock4 /safe -n

# Configure the GPIB interface
/usr/bin/gpib_config

# manually assign ip address (uncomment and edit as appropriate)
# note: first ifattach (no args) sets local loopback
/bin/ifattach

# Set the MAC and IP address
/usr/bin/setmac
/usr/bin/ipenet

# start up the internet superserver
/bin/inetd &

# run 2 sec delay
/usr/bin/me_sleep

#If the application was installed using a windows
#machine the files may not be executable so change
#the permissions just-in-case
chmod 777 /usr/bin/zfp

#Start up the application
/bin/sh -c /usr/bin/zfp &

# that's it... success
exit 0

Quote
I have tried so far things like:
* Replace RJ45 magnetics and Eth phy (suspected dead LAN input, that get NIOS CPU in FPGA stuck waiting) = no help.

It's also possible that eth0 initialization script didn't complete. The firmware update manual mentions the ip 169.254.115.202. Also, setenet script on /usr/bin further mentions the following ip/mac tables:

Code: [Select]
mac_address='00:80:40:00:20:AE'
ip_address='129.196.136.131'

case $1 in
    halfdome) mac_address='00:80:40:00:20:A6' ; ip_address='129.196.136.112' ;;
    mlandich) mac_address='00:80:40:00:20:A7' ; ip_address='129.196.136.116' ;;
    dbartley) mac_address='00:80:40:00:20:A8' ; ip_address='129.196.136.117' ;;
    zippy)    mac_address='00:80:40:00:20:A9' ; ip_address='129.196.136.119' ;;
    rdz)      mac_address='00:80:40:00:20:AA' ; ip_address='129.196.136.122' ;;
    denny)    mac_address='00:80:40:00:20:AB' ; ip_address='129.196.136.125' ;;
    jwitters) mac_address='00:80:40:00:20:AC' ; ip_address='129.196.136.129' ;;
    britz)    mac_address='00:80:40:00:20:AD' ; ip_address='129.196.136.130' ;;
    test1)    mac_address='00:80:40:00:20:AE' ; ip_address='129.196.136.131' ;;
    test2)    mac_address='00:80:40:00:20:AF' ; ip_address='129.196.136.200' ;;
esac

Note how close the mac address found here:
00:80:40:00:56:A9 [on the screenshot]

On my unit the mac address starts with 00:C0:, which might suggest that something is wrong on eth0 initialization. I'd suggest to ping and/or telnet these ips using an auto mdi-x adapter or crossover cable configured with an ip on the same subnet.

Some services to play with:
Code: [Select]
ftp-data 20/tcp
ftp 21/tcp
telnet 23/tcp
uptime 24/tcp
http 80/tcp

I think uptime can be useful to an automation task know that the unit is already warm-up. Telnet connection return an increasing number, not sure, but maybe tens of minutes, and immediately closes connection.

Quote
* Replaced outguard SDRAM = no help
* Replaced outguard FPGA (bought new Cyclone from Digikey) = no help
* Freezespray bunch of stuff around  = no help anymore. Originally it helped and made meter work randomly for shortime.

Any chance that the flash memory got its last breath from a cold breeze?

Quote
When it was working, it took about 10-20 seconds to boot from init screen, and you can hear relay click after 2-3 sec from power on. Now it however does not click anything, just sitting silly.

When zfp app is launched it adjusts measurements, and the relays fill their mag lungs to cry hello world!

Quote
Supervisor chip that drive reset to NIOS FPGA is ok, reset is correctly toggled high on power on. There is some life to SDRAM data pins, so it's doing something.
I tried to probe RS232 chip in hope to find debug CPU console output, but there was no signals.

I didn't see any indicia of console on tty on the files. I didn't even connect using serial yet, but I'd try 115200 baud, at least on later firmwares, since inittab file on /etc shows:
Code: [Select]
# inittab for uClinux
# Format:
# ttyline:termcap-entry:getty-command
  ttyS0:vt100:/bin/agetty 115200 ttyS0

# ttyS1:vt100:/bin/agetty 9600 ttyS1
# ttyS2:vt100:/bin/agetty 9600 ttyS2

# ttyJ0:vt100:/bin/agetty 115200 ttyJ0

Hope there's something like uboot halt on any key here...

Quote
So far best shot would be to trace JTAG to the debug connector, and connect USB Blaster, to try if anything can be done from that side (perhaps read back NOR flash).

I agree, but only if ethernet really not initialized, and also if we don't find any boot console at tty.

Quote
But it's a long shot, as we don't have binary image from the FW flash. 8846A update tool have only bits and pieces, but not the full dump binary.

I must say that the firmware seems to include the full firmware, in pieces, it's true, but integer pieces. After extracting recursively the firmware, we get a folder 'instruments_e6f0b851bdee_zg_ia_sf/884X/bin' holding the firmwares, with the following files: beta_noinfo_reversed.rbf,
busybox, f884x_versions, flashcp, flash_eraseall, jffs2.bin, me_sleep, u69_nios.flash, vmlinux.bin, vmlinuxRev14ptf.bin, vmlinuxRev17ptf.bin, zfp, zfp_837;
and the recipes under /884X/procedures show exactly where each image should go.

One last bit, restarting zfp app restores my measurement telnet connection at port 3490.  :popcorn:

Regards.
- J'ai vu une maison de cent mille francs.
- Comme c'est joli!
 

Offline TiN

  • Super Contributor
  • ***
  • Posts: 4206
  • Country: us
  • xDevs.com/live - 24/7 lab feed
    • xDevs.com
Re: Fluke 8846A repair shenanigans.
« Reply #63 on: November 06, 2018, 03:07:14 am »
Cudos for the investigations, that could be very helpful. Perhaps its possible to build "binary image" that can be flashed to new flash chip to try? My meter have 1.x few so there is no "source" update part for this version. But I'd love to try that and even buy programmer that can do TSSOP56 chips.
YouTube | Metrology IRC Chat room | Live-cam | Share T&M documentation? Upload! No MB limit, firmwares, photos.
 

Offline massivephoton

  • Contributor
  • Posts: 24
  • Country: br
Re: Fluke 8846A repair shenanigans.
« Reply #64 on: November 06, 2018, 01:12:54 pm »
Cudos for the investigations, that could be very helpful. Perhaps its possible to build "binary image" that can be flashed to new flash chip to try? My meter have 1.x few so there is no "source" update part for this version. But I'd love to try that and even buy programmer that can do TSSOP56 chips.

I think it's possible to build a binary. I'm not sure if mtdblock[0-4] really are partitions of the same flash chip. If so, we can find the offsets and create the image. Also, I can try to copy the entire 2.37 flash from my unit to a single file on a usb pendrive. Just don't know how to do it yet.

Also, the firmware 2.10.882.24 already includes full images to upgrade from 1.x:

Code: [Select]
09/29/06-16:59,null    [OG SW]
10/06/06-22:22,null    [IG SW]
09/26/06-15:16,null    [OG HW]
09/26/06-15:23,null    [IG HW]
Sep 27 2006,null       [OS Build]
r1,proc_649_130        [Rel. 1 --> Rel. 7: upgrade using proc_649_130]
04/02/07-08:10,null
10/06/06-22:22,null
09/26/06-15:16,null
09/26/06-15:23,null
Sep 27 2006,null
r2,proc_688_130        [Rel.2 --> Rel.7: upgrade using proc_649_130]
11/09/07-09:21,null
09/14/07-21:54,null
08/20/07-20:19,null
08/21/07-16:30,null
Aug 23 2007,null
r3,proc_837_200_082307 [Rel.3 --> Rel.7: upgrade using proc_649_130]
11/09/07-09:21,null
09/14/07-21:54,null
08/20/07-20:19,null
08/21/07-16:30,null
Oct 25 2007,null
r4,proc_837_200_102507 [Rel.4 --> Rel.7: upgrade using proc_649_130]
11/09/07-09:21,null
12/12/07-20:15,null
08/20/07-20:19,null
08/21/07-16:30,null
Nov 30 2007,null
r5,proc_837_201        [Rel.5 --> Rel.7: upgrade using proc_649_130]
11/09/07-09:21,null
02/15/08-18:44,null
08/20/07-20:19,null
08/21/07-16:30,null
Nov 30 2007,null
r6,proc_837_210        [Rel.6 --> Rel.7: upgrade using proc_649_130]
02/14/08-08:54,null
02/15/08-18:44,null
08/20/07-20:19,null
08/21/07-16:30,null
Nov 30 2007,null
r7,proc_882_210        [Rel.7 --> Rel.7: upgrade using proc_649_130]

For instance, the code for procedure proc_649_130 is:
Code: [Select]
connect,null
wiz,syst:rem
step,1
tcomm,rm /usr/bin/vmlinux.bin
tcomm,rm /usr/bin/u69_nios.flash
tcomm,rm /usr/bin/vmlinuxRev14ptf.bin
tcomm,rm /usr/bin/beta_noinfo_reversed.rbf
tcomm,rm /bin/busybox
fcwd,/usr/
fget,calparams
fcwd,/bin/
fput,busybox
fcwd,/usr/bin/
fput,vmlinuxRev14ptf.bin
fput,flashcp
fput,flash_eraseall
fput,zfp
fput,me_sleep
tcomm,chmod 777 /usr/bin/flashcp
tcomm,chmod 777 /usr/bin/flash_eraseall
tcomm,chmod 777 /usr/bin/me_sleep
tcomm,rm /usr/bin/config/*
tcomm,mv /usr/bin/vmlinuxRev14ptf.bin /usr/bin/vmlinux.bin
tcomm,/usr/bin/flashcp -v /usr/bin/vmlinux.bin /dev/mtd1
tcomm,rm /usr/bin/vmlinux.bin
disconnect,null
reboot_simple,null
connect,null
wiz,syst:rem
step,2
fcwd,/usr/bin/
fput,vmlinux.bin
tcomm,/usr/bin/flashcp -v /usr/bin/vmlinux.bin /dev/mtd2
tcomm,rm /usr/bin/vmlinux.bin
fput,beta_noinfo_reversed.rbf
tcomm,/usr/bin/flashcp -v /usr/bin/beta_noinfo_reversed.rbf /dev/mtd0
disconnect,null
reboot_simple,null
connect,null
wiz,syst:rem
step,3
tcomm,/usr/bin/flash_eraseall -j /dev/mtd3
tcomm,mkdir /mnt/jffs2_blk3
tcomm,chmod 777 /mnt/jffs2_blk3
tcomm,/bin/mount -t jffs2 /dev/mtdblock3 /mnt/jffs2_blk3 -n
tcomm,rm -Rf /mnt/jffs2_blk3/*
tcomm,dd if=/dev/mtd1 of=/mnt/jffs2_blk3/jffs2.bin
tcomm,flashcp -v /mnt/jffs2_blk3/jffs2.bin /dev/mtd1
disconnect,null
reboot_simple,null
connect,null
wiz,syst:rem
step,4
fcwd,/usr/bin/
fput,u69_nios.flash
restorecal,null
wiz,syst:rem
step,5
wiz,ig_download "/usr/bin/u69_nios.flash"
message,"UPDATE DONE"
disconnect,null
end,end

Procedure proc_882_210 does nothing, since the installed firmware is already release 7.
- J'ai vu une maison de cent mille francs.
- Comme c'est joli!
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf