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.
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:
#!/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
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:
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:
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.
* 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?
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!
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:
# 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...
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.
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.
Regards.