Fluke 289 not quite sorted.

[giosif]

Hi,

Apologies for piggybacking this thread, but thought I'd take advantage of the attention the conversations here have had recently and also save creating another thread.
I recently purchased a Fluke 289 from our loved & hated online auction site and this meter not only has the screen broken, but it doesn't exhibit any signs of life.
I mean, if I press the power button, it turns green, but it stays that way and doesn't turn off (watching some videos online, I see the button led should turn off once the meter has completed booting).
Also, testing "on the blind" some functions like continuity didn't work (no audio output).
Finally, using the useful information contributed to this thread, I checked for serial communication on the J5 port, but there was no output of any kind (checked with the scope and the TX line is High all the time).

So, I started checking the other things mentioned here:

• Y1 and Y2 are oscillating at the right frequencies
• pin 1 on U13 gets power
• all power rails are fine, with one exception: the 5V rail
• another measurement that didn't match was the 2.5V, but that's the reference voltage, not a power rail.

Now, tracing the above problematic power rail got me to U17, which is responsible with generating the 5V.
The input of the regulator is getting 9V, so we're good there, but this regulator also has an ENABLE pin which is active Low.
And, you guessed it, it is always High.
As such, no 5V rail and, checking further down the line, no 2.5V voltage reference output from U15 either, since it is being powered by the 5V rail.
Next, I checked who is keeping the U17 ENABLE pin High and I traced the connection to pin 72 on U13.

And this is where I'm stuck at the moment, as I don't know what to do next, to determine what makes U13 keep pin 72 High.
I guess it could be that U13 is toasted or that it is waiting for some signal before turning on the 5V rail, but never gets that signal.

Anyone any suggestions, please?

Thanks!

[say]

You may like to check this thread too.

https://r.tapatalk.com/shareLink?url=https%3A%2F%2Fwww%2Eeevblog%2Ecom%2Fforum%2Findex%2Ephp%3Ftopic%3D59991%2E0&share_tid=59991&share_fid=25658&share_type=t

[giosif]

You may like to check this thread too.

https://r.tapatalk.com/shareLink?url=https%3A%2F%2Fwww%2Eeevblog%2Ecom%2Fforum%2Findex%2Ephp%3Ftopic%3D59991%2E0&share_tid=59991&share_fid=25658&share_type=t

Thank you, say!
That is a very useful thread but which, unfortunately, significantly diminished my hope I might be able to resurrect this meter: all three caps - C46, C55 and C92 - measure short across their terminals (and are all tied to the battery negative).
Although, I don't know... I find it strange this tends to happen in most cases with a dead 289...
Also, these three caps are located quite apart from each other on the board and I am trying to imagine what kind of failure can lead to this short measurement across each of them.
Could it be a common power rail that, once the NXP goes bad, gets somehow shorted?
Let me ask on the other thread, then.

Thanks again!

[kjk24]

Hi,

here a pic of the PCB under MSP430, i replaced it on two meters and reprogrammed it via jtag this works fine.
i replaced also on both bad units the MC9328 but i made no foto  of the pcb i forgot it shame.

the tree units in my lab have PCB Rev. 014, 015, 027
my meters are switching on and the power led stays on, i have no console output and no communication on spi,rs232, no lcd
the specker make a short sound at switching it on.

there are two spi communication path from  MSP430 to MC9328 and from MSP430 to the Analog part of the meter for switching Analog switches adg714.
MSP430 to MC9328 8Bit 2Mhz
70 SDI
69 SDO
68 clk
67 cs

MSP430 to ADG714
48 clk
50 SDI
49 SDO

i try to find out howto enable the ram to get excess from the jtag of the MC9328 to flash the fw to the flashchip via j-flash .
attached readout address spaces from a working unit.

iam searching for mx1flash utility for programming the external flash connected to MC9328
 

[kjk24]

new fotos of the MC9328 & the Falsh & RAM

[kjk24]

i replaced on one board the flash chip with a empty one,

tryed to flash the contense from other peoples flash and my extractions to 0x10000000 with j-flash and j-link-edu programmer.
loadfile "Z:\data.bin", 0x10000000
The j-link sw returned error unspecific -1.

in the i.MX Development Tools User Guide is a description how to doit, but i have not such a file to test it:
in chapter: 2.1.3 Flashing Bootloader
"BSP/Bootloader/bin/AMDFlash/programBoot_b.txt"

who has knowlage how to write the bootloader iguess its redBoot @ 0x10000000 in the flash chip ?
please let us know 

other:
i add the bootloader jumper, and open a terminal program "9600-57600/8N1", and start the device connected to the rs232 pins next to the speaker.
it will respond with ":" when you type "a"
that means the chips first stage bootloader is alive.

[kjk24]

additional info

U20 is a pwm controller with two outputs one for 1.8V one for 2.8V both for the ARM cpu
the U13 the MSP CPU enable the outputs with 3.0V

R130 and R129 0Ohm
R130 for 1.8V rail
R129 for 2.8V rail
remove and test the pwm controller, it will divide the cpu from the powersupply

U26 CPU Boot Pins
TP16 = Boot0 & Boot2 normaly Hi
TP28 = Boot1 normaly Lo pulldown 1K
TP30 = Boot3 normaly Lo pulldown 1K

TP16 is the Boot jumper pullup with R134 85K
Jumper set = Boot from BootStrapRom
Jumper not set (Normal) = Boot from FlashRom CS0

Parts
R129 0R
R130 0R
R133 10k
R1345k
R132 1k
R128 10k
R124 10k
R141 1k
R140 1k
R139 1k
R138 1k
R137 1k


Testports
TP16 = Boot0 & Boot2 normaly Hi
TP28 = Boot1 normaly Lo pulldown 1K
TP30 = Boot3 normaly Lo pulldown 1K

TP18 = 1.8V
TP17 3.1V
TP16 2.91V
E29 RBinit Abort (pullup)
E30
E31
E32
E33
E33
E39
E38
E40

U26CPU Ports from Fluke clem Board definitions, not sure if all correct.
PortB are korrekt i ckeckt it.

/*---------------------------------------------------------------------------*/
// Pin assignments
// Format: MACRO_NAME (pin #)

// PORT A
#define MXS_TIN_PIN   (1)
#define BACKLIGHT_PIN (2)
#define HIBEAM_PIN    (3)
#define E30_PIN       (4)
#define _1V8_MODE_PIN (5)
#define _3V_MODE_PIN  (6)
#define E29_PIN       (7)
#define E31_PIN       (
#define E32_PIN       (9)
#define CRE_PIN       (10)
#define LCD_OFF_PIN   (11)
#define FAC_PROG_CNRL_PIN (12)
#define E33_PIN       (15)
#define E39_PIN       (16)

// PORT B
#define KEY_5_PIN  (
#define KEY_6_PIN  (9)
#define KEY_7_PIN  (10)
#define KEY_1_PIN  (12)
#define KEY_2_PIN  (13)
#define KEY_3_PIN  (14)
#define KEY_4_PIN  (15)
#define MODEL_A_PIN   (16)
#define MODEL_B_PIN   (17)
#define KEY_9_PIN  (18)
#define KEY_10_PIN  (19)
#define KEY_11_PIN  (20)
#define KEY_12_PIN  (21)
#define KEY_13_PIN  (22)
#define KEY_14_PIN  (23)
#define KEY_8_PIN  (24)
#define UART2_TXD_PIN (30)
#define UART2_RXD_PIN (31)

// PORT C
#define UART1_TXD_PIN (11)
#define UART1_RXD_PIN (12)
#define SPI_CS_PIN    (13)
#define SPI_SCLK_PIN  (14)
#define SPI_INT_PIN   (15)
#define SPI_MISO_PIN  (16)
#define SPI_MOSI_PIN  (17)

// PORT D
#define BOARD_ID_0    (23)
#define BOARD_ID_1    (24)
#define BOARD_ID_2    (25)
#define BOARD_ID_3    (26)
#define BOARD_ID_4    (27)
#define BOARD_ID_5    (28)
#define BOARD_ID_6    (29)
#define BOARD_ID_7    (30)
#define BEEP_PIN      (31)
plf_hardware_init(void)
{
    const PORT_INIT portInit[] = {                // NAME ON SCHEMATIC DIAGRAM
#ifdef FOR_REDBOOT
        {PORT_A, MXS_TIN_PIN, PIN_INPUT_HIZ},     // 1, MXS_TIN (interrupt
                                                  // from eth)
#endif
        {PORT_A, BACKLIGHT_PIN, PIN_OUTPUT_LOW},  // 2, BACKLIGHT
        {PORT_A, HIBEAM_PIN, PIN_OUTPUT_HIGH},    // 3, HIBEAM
        {PORT_A, E30_PIN, PIN_OUTPUT_LOW},        // 4, E30
        {PORT_A, _1V8_MODE_PIN, PIN_OUTPUT_HIGH}, // 5, 1V8_MODE
        {PORT_A, _3V_MODE_PIN, PIN_OUTPUT_HIGH},  // 6, 3V_MODE
//        {PORT_A, E29_PIN, PIN_OUTPUT_LOW},        // 7, E29
        {PORT_A, E29_PIN, PIN_INPUT_PULLUP},        // 7, E29
        {PORT_A, E31_PIN, PIN_OUTPUT_LOW},        // 8, E31
        {PORT_A, E32_PIN, PIN_OUTPUT_LOW},        // 9, E32
#ifdef FOR_REDBOOT
        {PORT_A, CRE_PIN, PIN_OUTPUT_LOW},        // 10, CRE
#endif
        {PORT_A, LCD_OFF_PIN, PIN_OUTPUT_LOW},    // 11, LCD_OFF
        {PORT_A, FAC_PROG_CNRL_PIN, PIN_INPUT_PULLUP},  // 12, FAC_PROG_CNTL
                                                        // (normally unused)
        {PORT_A, E33_PIN, PIN_OUTPUT_LOW},        // 15, E33
        {PORT_A, E39_PIN, PIN_OUTPUT_LOW},        // 16, E39
        {PORT_A, 17, PIN_INPUT_PULLUP},           // 17, See chip errata

        {PORT_B, KEY_5_PIN, PIN_OUTPUT_LOW},   // 8, KEY_5
        {PORT_B, KEY_6_PIN, PIN_OUTPUT_LOW},   // 9, KEY_6
        {PORT_B, KEY_7_PIN, PIN_OUTPUT_LOW},   // 10, KEY_7
        {PORT_B, KEY_8_PIN, PIN_OUTPUT_LOW},   // 11, KEY_8
        {PORT_B, KEY_1_PIN, PIN_OUTPUT_LOW},   // 12, KEY_1
        {PORT_B, KEY_2_PIN, PIN_OUTPUT_LOW},   // 13, KEY_2
        {PORT_B, KEY_3_PIN, PIN_OUTPUT_LOW},   // 14, KEY_3
        {PORT_B, KEY_4_PIN, PIN_OUTPUT_LOW},   // 15, KEY_4
        {PORT_B, MODEL_A_PIN, PIN_INPUT_HIZ},     // 16, MODEL_A
        {PORT_B, MODEL_B_PIN, PIN_INPUT_HIZ},     // 17, MODEL_B
        {PORT_B, KEY_9_PIN, PIN_OUTPUT_LOW},   // 10, KEY_9
        {PORT_B, KEY_10_PIN, PIN_OUTPUT_LOW},   // 11, KEY_10
        {PORT_B, KEY_11_PIN, PIN_OUTPUT_LOW},   // 12, KEY_11
        {PORT_B, KEY_12_PIN, PIN_OUTPUT_LOW},   // 13, KEY_12
        {PORT_B, KEY_13_PIN, PIN_OUTPUT_LOW},   // 14, KEY_13
        {PORT_B, KEY_14_PIN, PIN_OUTPUT_LOW},   // 15, KEY_14

// For some reason, the SPI output ports can not be reset. Doing so causes the
// Clem application to not work.
#ifdef FOR_REDBOOT
        {PORT_B, UART2_TXD_PIN, PIN_MODULE},      // 30, UART2_TXD
        {PORT_B, UART2_RXD_PIN, PIN_MODULE_PULLUP}, // 31, UART2_RXD
                                                    // (normally unused)

        {PORT_C, UART1_TXD_PIN, PIN_MODULE},      // 11, UART1_TXD
        {PORT_C, UART1_RXD_PIN, PIN_MODULE},      // 12, UART1_RXD
        {PORT_C, SPI_CS_PIN, PIN_OUTPUT_HIGH},    // 13, MXS_CS   (SPI)
        {PORT_C, SPI_SCLK_PIN, PIN_OUTPUT_LOW},   // 14, MXS_SCLK (SPI)
#endif
        {PORT_C, SPI_INT_PIN, PIN_INPUT_HIZ},     // 15, MXS_INT  (SPI)
        {PORT_C, SPI_MISO_PIN, PIN_INPUT_HIZ},    // 16, MXS_MISO (SPI)
#ifdef FOR_REDBOOT
        {PORT_C, SPI_MOSI_PIN, PIN_OUTPUT_LOW},   // 17, MXS_MOSI (SPI)
#endif

        {PORT_D, 6, PIN_OUTPUT_LOW},              // 6, LSCLK    (LCD)
        {PORT_D, 11, PIN_OUTPUT_HIGH},            // 11, CONTRAST
        {PORT_D, 12, PIN_OUTPUT_LOW},             // 12, LCD_M
        {PORT_D, 13, PIN_OUTPUT_LOW},             // 13, LCD_LP
        {PORT_D, 14, PIN_OUTPUT_LOW},             // 14, LCD_FLM
        {PORT_D, 15, PIN_OUTPUT_LOW},             // 15, LD0
        {PORT_D, 16, PIN_OUTPUT_LOW},             // 16, LD1
        {PORT_D, 17, PIN_OUTPUT_LOW},             // 17, LD2
        {PORT_D, 18, PIN_OUTPUT_LOW},             // 18, LD3
        {PORT_D, 19, PIN_INPUT_PULLUP},           // 19, LD4 (unused)
        {PORT_D, 20, PIN_INPUT_PULLUP},           // 20, LD5 (unused)
        {PORT_D, 21, PIN_INPUT_PULLUP},           // 21, LD6 (unused)
        {PORT_D, 22, PIN_INPUT_PULLUP},           // 22, LD7 (unused)
        {PORT_D, BOARD_ID_0, PIN_INPUT_PULLUP},   // 23, Board ID 0
        {PORT_D, BOARD_ID_1, PIN_INPUT_PULLUP},   // 24, Board ID 1
        {PORT_D, BOARD_ID_2, PIN_INPUT_PULLUP},   // 25, Board ID 2
        {PORT_D, BOARD_ID_3, PIN_INPUT_PULLUP},   // 26, Board ID 3
        {PORT_D, BOARD_ID_4, PIN_INPUT_PULLUP},   // 27, Board ID 4
        {PORT_D, BOARD_ID_5, PIN_INPUT_PULLUP},   // 28, Board ID 5
        {PORT_D, BOARD_ID_6, PIN_INPUT_PULLUP},   // 29, Board ID 6
        {PORT_D, BOARD_ID_7, PIN_INPUT_PULLUP},   // 30, Board ID 7
        {PORT_D, BEEP_PIN, PIN_OUTPUT_LOW},       // 31, BEEP
    };

the init sequence (Register settings) for the U26 CPU
who have the Redboot running and output on the uart ?

example:
RedBoot>dump -b 0x100000 -4
00100000: DEADFACE DEADFACE DEADFACE DEADFACE

i need them Register contens of Address:
0x00200000 - 0x00223fff

the command for it sould:
dump -b 0x00200000 -4 -l 0x2 3FFF


need the RAM Register settings to init the RAM and have access to it,
the device is still not booting redboot from flash, now i like to flash the redboot bootloader into the flash again to see if its help.
best regards
kai

[kjk24]

Hello Kaiser thanks for your PN,

No iam not further,  i have still 3 units not running.
But i changed both cpu's and ram and flash. The units start only to boot mode like yours.
The flash programming is done with a script i guess over rs232 interface.
I cant programm the flash, i tryed to fiigure out how to get the ram intitial to but no succsses.
If you connect seeger debuggeer you should have access to the cpu regist er.

Hope i have time and luck in the future to fixit.
Greetings
Kai

[kjk24]

Hello Kaiser,

i have 3 Meters on all C11, C26, C54 short and no Voltage across if its on (to turn it on i press on and the led is lightning nothing else hepend)

have a simular problem on one meter, MXS getting hot. i desoldered R129 (0Ohm), R130 (0Ohm) to check if the dcdc rails are ok, 2.8V and 1.8V next to TP18, TP17.
you can power the CPU from a external supply to see how much mA it sucks.
i replaced the CPU and it get not hot anymore and boot into MXS Bootloader only!

i check now how you able to upload code to the Flash, iam not able to make it happen.
best regards
kai

[kjk24]

Hi Kaiser,
lets discuse here , other people may need the info too.

Hi Kaiser,

no display attatched , and boot jumper set !

Meter1 C56=0V, C58=20V, C62=0V, C59= 0.9V, C61= 0V
Meter2 C56, C58, C62, C59= 1.2V, C61= 15.6V,
Meter3 C56, C58, C62, C59= 1.2V, C61= 15.6V,

Meter1 C56, C62, C59, C61, C58=2mV, C98 =0V (should ~20VDC) iguess Q43 bad on bottom, i have to check.
    no its ok, its a P channel Mosfet, U21 the PWM ic for the 20V, Q42 a NPN is witched on by U13 Pin73
   i disconnected this in on U13 a wile ago ! i reconnect it and the 20V are there.



best regards
kai

[kjk24]

some infos & thank to Kaiser

RedBoot Abort Pin E29 next to J4
pull it low with pulldown resistor for aborting Redboot to boot

SPLASH_BMP_FLASH_ADDR 0x107C0000

1. flash redboot only
2. fis init

--------------------
bootscript :

3. fconfig- l show config

4. fconfig -i
Initialize non-volatile configuration - continue (y/n)? y
Run script at boot: true
Boot script:
Enter script, terminate with empty line
>> fis unlock fs
>> fs mount -d /dev/flash/fis/fs -t jffs2 /
>> load -m file /system/apps/clem.img
>> fs umount /
>> go -c -n -w 10000
>>
Boot script timeout (1000ms resolution): 10
Use BOOTP for network configuration: false
Gateway IP address:
Local IP address:
Local IP address mask:
Default server IP address:
Console baud rate: 115200
DNS server IP address:
Set eth0 network hardware address [MAC]: false
GDB connection port: 9000
Force console for special debug messages: true
Console number for special debug messages: 0
Network debug at boot time: false
Update RedBoot non-volatile configuration - continue (y/n)? y

copy file to device:
load clem.img -r -b 0x00050000 -m ymodem
fs write -b 0x00050000 -l 0x003bd617 clem.img
RedBoot> fs list
   3 drwxr-xr-x  1 size      0 .
   2 drwxr-xr-x  1 size      0 ..
   4 -rwxr-xr-x  1 size 3921431 clem.img
RedBoot>

reset

SerialNumber @ 0x1DEB60

Rev015
without VR1,VR2 etc.
R121/125 assembeld ModellA
no Jumper ID's on Board

Rev020
without VR1,VR2 etc.
R121/125 assembeld ModellA
R277 (1K pulled down) assembeld ID0

Rev027
without VR1,VR2 etc.
R121/125 assembeld ModellA
R277 (1K pulled down) assembeld ID0
R278 (1K pulled down) assembeld ID1

Rev024
with VR1,VR2 etc.
R121/126 assembeld ModellB
R277 (1K pulled down) assembeld ID0
R278 (1K pulled down) assembeld ID1

[kjk24]

for me the Project is finished, i repaired all my 3 dmm.
Thanks to Kaiser he help me a lot.

all infos on your own risk, you can damage your filesystem or calibration or whatever.
dont touch it if you dont sure what you do.

here some infos.

1. dmm switch on and the LCD flickers and not normal screen, check U19 voltages and R101
see attached pic
2. dmm switch on and the LCD hang with a bark, check SPI communication from MXS to MSP
3. dmm switch on and the LCD has additional lines on the screen check ram
4. dmm switch on and bootlogo hang, check clem.img or CRC on flashdrive

my fails on the units wars: LCD Voltage bad (R101) cracked, MXS CPU dead, Ram bad, flash bad, most annoying bad via under MXS (Mosi) to MSP, LCD brocken, batterie metall thing brocken on 2 units.

boot to redboot:
1K pulldown to E29 and switch on, type ctrl-C or space on RS232 Terminal ( i used extra putty)

check RAM:
 boot into redboot becorse the ram has to be initialised, try to read and write to ram or use J-MEM with the  (MC9328MXS.jflash file for initram) and write and read FF and 00 to 0x12000000-0x12FFFFFF

CRC:
 boot into redboot check for a message "somthing with CRC not correct" then some is with filesystem wrong.

clem.img: (extra putty with ymodem)
 boot into redboot and look for the clem.img if its there
>fis unlock fs
>fs mount -d /dev/flash/fis/fs -t jffs2 /
>fs cd /system/apps/
RedBoot> fs list
   6 drwxr-xr-x  1 size      0 .
   3 drwxr-xr-x  1 size      0 ..
 621 -rwxr-xr-x  1 size 3921431 clem.img
 596 -rwxr-xr-x  1 size 3922423 BackupClem.img

copy clem.img to flash via RS232 (115200 8N1 on J5):
 boot into redboot
 fis unlock fs
 fs mount -d /dev/flash/fis/fs -t jffs2 /
 fs cd /system/apps/
 fs list
 fs move clem.img BackupClem.img
 load clem.img -r -b 0x00050000 -m ymodem
 fs write -b 0x00050000 -l 0x003bd617 clem.img
 RedBoot> fs list
   6 drwxr-xr-x  1 size      0 .
   3 drwxr-xr-x  1 size      0 ..
 621 -rwxr-xr-x  1 size 3921431 clem.img
 596 -rwxr-xr-x  1 size 3922423 BackupClem.img
 RedBoot> reset

check redboot bootscript:
boot into redboot,
fconfig -l show config

change the bootscript with wait 10seconds to boot:
fconfig -i
Initialize non-volatile configuration - continue (y/n)? y
Run script at boot: true
Boot script:
Enter script, terminate with empty line
>> fis unlock fs
>> fs mount -d /dev/flash/fis/fs -t jffs2 /
>> load -m file /system/apps/clem.img
>> fs umount /
>> go -c -n -w 10000
>>
Boot script timeout (1000ms resolution): 10
Use BOOTP for network configuration: false
Gateway IP address: 0.0.0.0
Local IP address: 192.168.9.133
Local IP address mask: 255.255.0.0
Default server IP address: 192.168.100.100
Console baud rate: 115200
DNS server IP address: 0.0.0.0
Set eth0 network hardware address [MAC]: true
eth0 network hardware address [MAC]: 0x00:0x80:0x40:0x00:0x22:0x85
GDB connection port: 9000
Force console for special debug messages: true
Console number for special debug messages: 0
Network debug at boot time: false
Update RedBoot non-volatile configuration - continue (y/n)? y

LCD:
J3 (LCD)
1= +20V
2= +18.8V
3= +17.6V
4= +2.4V
5= +1.2V
6= GND
7= GND
8= ?
9-18= Data
19= +9V
20= ? Backlight
if Voltage not correct check R101 & U19


redboot found clem.img and booting it:


MSP Chip bad or communication to it bad:


redboot dont find clem.img bootloader hang:
[ Specified attachment is not available ]


Regards
Kai

[goaty]

Wanted to add something I encountered, which might not have to do anything with the Fluke problems, but I thought it might fit:

I have a set of Mastech cable finder which use MSP430F135.

Both sender and receiver have a problem and did not start reliable.
I found that the decoupling caps are very very critical on the analog and digital supply lines.
In the sender, I managed to get it starting up after replacing the caps. Before it had excessive current draw. 3.3V regulator got hot and CPU was not running.

On the receiver it also does not start up, but caps replacement did not help.
I have the suspicion that the MSP430 is very sensitive.

[kaiser]

Might come in handy for some..
Here is a J-Flash config setting to read and write to the flash with the use of Flukes onboard RAM which I used on my 289.

In the J-Flash CPU tab, tick "Use target RAM" : write time = approx 2min..
Not ticked write time = approx 5Hrs...... for each write

J-Flash ARM V4.20a was used in this case.


K.
                         

[nixxon]

Update from my side:
(...)
@Nixxon:
If your unit is not doing anything anymore, check if U17 is actually giving juice (even when powered off.
U17 =  Code PCYI -> TPS770 -> Power 5V   ULTRALOW-POWER 50-mA LOW-DROPOUT LINEAR REGULATORS
(...)

I have now started all over again troubleshooting my dead 289. I  am going through all posts regarding 289 troubleshooting in this forum. My 289 has entered the 5x flashing power button state (dead mode). There is no output from the 5V regulator U17 (TP3). This is probably because the enable input pin 3 (EN) of the TPS770 reads 3.1 Volts ("A voltage of 1.7 V or greater on the EN input will disable the TPS770xx internal circuitry...). Does anyone know which component has decided to shut off the 5V regulator by feeding 3.1V to the EN-pin of U17?

[kjk24]

Hi nixxon,

the Regulator until the lcd show the regular application is off, u17 is switched on from MSP430 when the app is running (LCD shows it)
it has prop nothing todo with the error message.
check if the bootloader can load the app. by connecting rs232 and bootloader jumper..... see older posts.

[MihaiV]

Hello everyone,

I saw a cheap and faulty Fluke287/NUC on ebay. The seller said it shows the leads connection error on any setting, so I went for it.
A different meter with a different fault arrived, and the other one was already gone. Shipping it back would have been more expensive than the unit itself, so I kept it.

At power-up, it lights the led for 1 second, than it blinks very shortly and it make an extremely short beep, it displays the Fluke logo and the led turns off (as it should) and the screen goes gray when it should display its measurements.

No button is active, switching functions does nothing and it can only be turned off by removing the batteries.

On some occasions the display does not turn on at all.

Let's inspect: no damage at all on the case, the screen has its protection foil on. Input terminals clean.
Inside: no sign of input damage: MOVS have "infinite" resistance, PTC, 1K resistor and the high voltage resistor are ok. The fuse is missing though... The board is clean, no sign of fluid damage anywhere. It appears someone was here before: the screws from the input terminals indicate that an unsuitable screwdriver was used to remove them.

Anyway: the back-up capacitor was a bit corroded but it did not leak. I removed it.
I measured all power rails for shorts: the 21V for the LCD, the 3.3V for MSP, the 1.8V and the 2.9V, the 5V and the 2.5V reference, and finally the LCD display outputs from the LP324. I found none. Next, I checked all jelly-bean semiconductor: all diodes (CR and VR) and all transistors (from the posts above), are ok, no shorts, no obvious conduction in both ways.

Now apply power: 9V through the battery pads. I see the 3.2V for the MSP is on and all capacitors around it measure the same, except C41. This is the external ADC reference input, taken from the voltage reference. No other voltage is present on any other test points and caps.

Power on:
- The dual buck provides 2.94V (158KHz switching frequency, 98% duty cycle, 0.958V at the feedback pin) and 1.8V (300KHz switching, 92% duty cycle and 0.904V at the feedback pin).
   
- The 21V boost converter is on and U19 (LP324) provides voltages close to the ones from the previous posts: 1.31V, 2.62V, 18.55V and 19.8V. While at it, I also checked the opa-mp operation but there was no significant difference from the inverting and non-inverting inputs (<1mv)
   
- U17 outputs only 0.58V... But it is not faulty, it is disabled by the MSP. I checked that trace and it is not shorted to VCC. So, no 5V and no 2.5V reference output. No other voltage is present on any capacitor in the analog section, including the ADC.
   
- A look with a thermal camera didn't show anything. The 2.9V + 1.8V converter and the MXS were barely showing up, everything else was cold.
   
After several power-ups, I noticed that the display only operates when my hand is near the main processor, U26. Pressing lightly on it made the display show the logo every time. So I reflowed it (and the Flash + RAM chips while at it) at the university with a dedicated BGA rework station, and that partly fixed the problem. The display shows the logo every time.

But the display still becomes gray after the logo and the led. What I noticed is that after removing the power, a single horizontal line briefly remains on the display, fading away in less than 1 second. So it appears it continuously sweeps the screen, making it gray.

Here is what I measured on the LCD connector:
   1. 21.1V constant.
   2. 19.26V constant.
   3. 18.55V constant.
   4. 2.62V constant.
   5. 1.32V constant.
   6. 0V
   7. 0V
   8. 2.94V constant.
   9. Square wave, 171Hz, 50% duty cycle, 3V logic.
   10. Square wave, 75Hz, 0.8% duty cycle, 3V logic, appears to be a syncro signal.
   11. Square wave, 18.1KHz, 3.6% duty cycle, 3V logic.
   12. 2.94V constant.
   13. Square wave, 1.67MHz, 50% duty cycle, 3V logic. Looks like a clock signal.
   14. 0v
   15. 0V, goes towards the MXS.
   16. 0V
   17. 0V, goes towards the MXS.
   18. 0V
   19. 9V (from supply)
   20. 0V, connected to the collector of Q17. Appears to be the cathode of the backlight.
   
The LCD itself appears ok, since it correctly displays the Fluke logo. The ribbon cable looks good to, no sharp bends or interruptions.

I also checked the crystals: the MSP 32.768KHz crystal resonates near enough (32.77KHz), with 200mVpp.
The MXS crystal shows a 32.7KHz wave on one side (as if half-wave rectified) and nothing on the other pin.
I changed it with a different one and it resonates nicely now on one side, with 900mVpp. The other side still appears like a half-wave rectified sine.

However, this still does not change anything, the LCD is still gray after booting.

As indicated in previous posts, I checked the SPI connection between the MXS and the MSP. I see data, clock and CS on all of them, with nice clean transitions. Data is being exchanged every time the ON button is pressed. The MXS also responds something when turning on and before powering off. If the power button is pressed for 5s continuously it reboots.

Speaking of booting, I also sniffed J5, a serial interface. Immediately after power-on, I get a "+" character, and right before gray-screening I get "Entry point: 0x00060040, address range: 0x00060000-0x003bef68" followed by a carriage return and a line feed. This looks like the output of a healthy meter (seen on one post above). This indicates that it can communicate with the flash memory, since MXS is only a processor, taking its program from the flash chip.

I started to focus on the MSP not enabling the 5V regulator. The scope shows that it does enable it, immediately after power-up. It pulls it down for 20ms and than it disables it again. The regulator appears to be working, as it outputs 5V. The reference is also ok, providing 2.5V at the MSP ADC reference input (for those 20ms).

I also noticed that the IR led does not blink to detect the probe connection. The driving transistor measures ok, the led lights up on the camera and the trace to the MSP is not interrupted (the pins are all well soldered too).

And here is where I got stuck.
I only have two (rather cold) leads: a faulty solder joint or via in the LCD data bus, since pins 15 and 17 are always 0v and both go to the MXS (but why does the start-up logo display correctly ?) and the weird driving signal for the MXS crystal (but MXS boots and displays proper message on the serial interface).

None of them appear connected to disabling the analog 5V rail.
Sorry for the long bed-rime story...

Any ideas on what else can I check?

Thanks,
MihaiV

[MihaiV]

Here come the rest of the photos. This is the one with the gray screen.

[MihaiV]

Immediately after removing the power, a single line briefly remains on the display. It is interesting that the conductive line from "beyond" the pixel array is also showing in black (at the edges). During "normal" operation is is not visible though.

The console output at booting is in the second attachment.
I also tried to send Ctlr-C during booting, but that simply hangs the power led in the on state and does nothing else.

[YetAnotherTechie]

The line on the lcd doesn't mean that it's bad, it just means that it was an uncontrolled shutdown, i.e. the lcd drivers were not turned off in software before power went unregulated.

[MihaiV]

Hi YetAnotherTechie,

Agreed, it is a sudden shutdown and it always displays another line, wherever it happens to be when power goes out.
I am curious if the two lines that are always low (pin 15 and 17) are driven somehow in a functional meter.
The scope shows that the clock signal is continuously going. But what you said points out that is is not necessarily writing only 1s and it might not be a single line that scans from top to bottom like crazy.

I will return with a 4 channel oscilloscope to check more signals at the same time.
But the fact that the MSP does not enable the 5V rail indicates that the MXS is still not operating properly and the application is not correctly running. MSP might expect a specific message on the SPI from the MXS.

[MihaiV]

Good evening,

I did replace the crystal on the MXS chip, as it showed no signal on one of its pins. I could only see the driving signal from the IC. The new one does resonate with fairly high amplitude but I have a doubt concerning the driving part.

Pictures 3 and 4 are the scope captures of each MXS crystal pins. Is this how it's supposed to look?
Pictures 1 and 2 are coming from the each of the MSP crystal pins and the driver looks  different. The driving signal does have a DC offset, so it can do a complete sinusoid (or close to it).

Could the crystal driving part be faulty or the driver in here simply does not need a full sinusoid swing and it does not use a DC offset for it?

While at it, I also captured a the brief moment in which the 5V analog power rail is enabled (picture 5). This happens immediately after pressing the power button, way before the logo on the display vanishes, so it does not appear to be related to the MXS not running its application. Does anyone know if MSP checks something during this sequence, or measures something and that is not right (and shuts down the power) ?

Thanks,
MihaiV.

[bdunham7]

I don't mean to interrupt anyone's repair, but since the topic is not quite sorted F289s, can anyone tell me how long the memory/date/time should be retained by the supercap with the batteries removed?  Fluke's online tech support seems to be suffering and their rep couldn't answer questions with anything but nonsense.  Mine is v1.16, had the supercap serviced by Fluke last year and loses the memory in less time than it takes me to charge the Eneloops that I use in it.  It works fine otherwise and doesn't drain the batteries unreasonably.

[alex_hobeanu]

I removed the batteries on mine for 24 hours and found the date / time to be correct after I put them back and power up the meter.
I have no data stored in the meter but the rtc ran fine so I guess there was enough energy stored internally to keep the memory alive.
Fluke 289 serial # 41840060 (March 2018), firmware version 1.16 / V0.88.

[bdunham7]

I removed the batteries on mine for 24 hours and found the date / time to be correct after I put them back and power up the meter.
I have no data stored in the meter but the rtc ran fine so I guess there was enough energy stored internally to keep the memory alive.
Fluke 289 serial # 41840060 (March 2018), firmware version 1.16 / V0.88.

Thank you for checking that.  Mine is older, 2011 or so, but AFAIK, there are only two versions  and yours is the same FW level as mine, so it is the 'older' version.