SC573 EZ-Kit not booting from Add-In's U-Boot image, lights FAULT LED, nothing on terminal

My ADSP-SC573 EZ-Kit no longer boots, even from the u-boot-sc573-ezkit.ldr that comes as part of Add-In v1.2.0 for CCES v1.2.0:

U-Boot 2015.01 ADI-1.2.0 (Jul 26 2017 - 13:47:35), Build: jenkins-IP119-UBOOT-STAGE-DEB-label=make_deb_package-305

CPU: ADSP ADSP-SC573-0.0 (Detected Rev: 1.1) (spi flash boot)
VCO: 450 MHz, Cclk0: 450 MHz, Sclk0: 112.500 MHz, Sclk1: 112.500 MHz, DCLK: 225 MHz
OCLK: 150 MHz
I2C: ready
DRAM: 224 MiB
MMC: SC5XX SDH: 0
SF: Detected W25Q128BV with page size 256 Bytes, erase size 4 KiB, total 16 MiB
In: serial
Out: serial
Err: serial
other init
Net: dwmac.3100c000
Hit any key to stop autoboot: 0
sc # dhcp
Speed: 100, full duplex
BOOTP broadcast 1
BOOTP broadcast 2
DHCP client bound to address 192.168.1.101 (754 ms)
sc # printenv
addip=set bootargs ${bootargs} ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname}:eth0:off
autoload=no
baudrate=57600
bootargs=root=/dev/mtdblock2 rw rootfstype=jffs2 clkin_hz=(25000000) earlyprintk=serial,uart0,57600 console=ttySC0,57600 mem=224M
bootcmd=run ramboot
bootdelay=5
dnsip=192.168.1.1
dtbaddr=0x84000000
dtbfile=sc573-ezkit.dtb
ethact=dwmac.3100c000
ethaddr=02:80:ad:20:31:e8
fileaddr=82000000
filesize=44c4c
gatewayip=192.168.1.1
hostname="sc57x"
ipaddr=192.168.1.101
loadaddr=0x82000000
loads_echo=1
nc=set ncip ${serverip};set stdin nc;set stdout nc;set stderr nc
netmask=255.255.255.0
nfsargs=set bootargs root=/dev/nfs rw nfsroot=${serverip}:${rootpath},tcp,nfsvers=3
nfsboot=tftp ${loadaddr} ${nfsfile};run nfsargs;run addip;bootm
nfsfile=vmImage
ramargs=set bootargs root=/dev/mtdblock2 rw rootfstype=jffs2 clkin_hz=(25000000) earlyprintk=serial,uart0,57600 console=ttySC0,57600 mem=224M
ramboot=tftp ${loadaddr} ${ramfile};tftp ${dtbaddr} ${dtbfile};run ramargs;run addip;bootm ${loadaddr} - ${dtbaddr}
ramfile=uImage
rootpath=/romfs
serveraddr=b8:ca:3a:8d:94:7c
serverip=192.168.1.1
stderr=serial
stdin=serial
stdout=serial
ubootfile=u-boot.ldr
update=tftp ${loadaddr} ${ubootfile};sf probe 2:1;sf erase 0 0x80000;sf write ${loadaddr} 0 ${filesize}

Environment size: 1350/8188 bytes
sc # set serverip=192.168.1.102
## Error: illegal character '='in variable name "serverip=192.168.1.102"
sc # set serverip 192.168.1.102
sc # ping ${serverip}
Speed: 100, full duplex
Using dwmac.3100c000 device
host 192.168.1.102 is alive
sc # sf probe 2:1
SF: Detected W25Q128BV with page size 256 Bytes, erase size 4 KiB, total 16 MiB
sc # sf erase 0 0x1000000
SF: 16777216 bytes @ 0x0 Erased: OK
sc # run update
Speed: 100, full duplex
Using dwmac.3100c000 device
TFTP from server 192.168.1.102; our IP address is 192.168.1.101
Filename 'u-boot.ldr'.
Load address: 0x82000000
Loading: ####################
1.9 MiB/s
done
Bytes transferred = 281676 (44c4c hex)
SF: Detected W25Q128BV with page size 256 Bytes, erase size 4 KiB, total 16 MiB
SF: 524288 bytes @ 0x0 Erased: OK
SF: 281676 bytes @ 0x0 Written: OK
sc # save
Saving Environment to SPI Flash...
SF: Detected W25Q128BV with page size 256 Bytes, erase size 4 KiB, total 16 MiB
Erasing SPI flash...Writing to SPI flash...done
sc #
------------- power-cycle or hardware reset here -------------

I get nothing at all in the terminal where I normally get the "sc #" U-Boot prompt, and the FAULT LED is on. I can't figure-out why I can run the same u-boot-sc573-ezkit image (same code, different format) from OpenOCD/GDB/JTAG (per Linux Add-In v1.2.0 User Guide section 2.1.3 "Flashing U-Boot for the First Time", but not when I 'run update' it from my TFTP server. Only LED9 (PWR), LED10, LED17, LED1 (FAULT) are on, even after erasing all 16 MB of Flash before entering 'run update'. I've checked the hardware configuration to ensure it's the same as the defaults shown in the ADSP-SC573 EZ-KIT Manual's Figure 2-1: "Default Hardware Setup".

There's not much I can mess-up here (vendor-supplied binary image, no custom configs or code). I just don't know how much further back I can backtrack to something that worked fine for weeks. The whole thing is on an anti-ESD mat, and even though I doubt it's got anything to do with network connectivity since the TFTP transfer completes without error, I swapped the Ethernet cables between the host & target (alone on their own switch), just in case. I'm looking with CCES to try to pin-point the source of the fault. Any other ideas?