GW-Instek GDM-8261A Bench Multimeter Firmware Update failed

[maralb]

I bought a used GW-Instek GDM8261A 6.5 digit bench multimeter some time ago from EBay. The instrument was in a very good condition with a crisp display and it really served me well.

I contacted GW-Instek for some questions about the instrument and if there was a Firmware Update available for it. It was running V1.02 and I got V1.03 from GW-Instek's Tech Support. Although the whole update procedure went as described by the update guide my instrument never came back to life afterwards. I asked GW-Instek for the older V1.02 firmware which I got but that resulted in the same thing. The instrument is turning its internal fan at full power but remains dead as a rock.

What followed was a disappointing experience with GW-Instek's repair service and support. They cannot or don't want to help me anymore leaving me with a bricked instrument.

I don't know why the procedure went wrong. There might be an internal hardware problem but I also don't rule out I got firmware update files for other hardware revisions. I opened the device and don't see any previous repairs or dodgy things inside. The instrument is maiden internally.

Anyone having similar experiences with this GW-Instek GDM-8261A Bench multimeter or recovered one after similar problems? Or having other Firmware images I could try on my instrument?

I included the update instructions for the GDM8261A and the 2 Motorola S-record Firmware Updates I received. Warning: I bricked my device with those!

[coromonadalix]

can you share the : LM Flash Programmer software requested for the FW update,   some  may poke in it to see things

appaently it come from TI
https://www.ti.com/tool/LMFLASHPROGRAMMER#downloads


they have an universal tool,  not sure it support he meter mcu,  check in their supported list
https://www.ti.com/tool/UNIFLASH

OK got it (lmflash programmer .... )  from GW  im registred there ...


all drivers installed and recognized in windows device manager ?   

they are .s19 files   not supposed to be like this, it sould be  .bin or.hex files

and here's seem to be a model A and not A  ?? on some pictures / web sites weird  maybe you got the wrong ones

and the mistake many people do, aint broke, do nothing ..... if it was working ok   you should not have tried an update ....

[maralb]

It definately is a GDM-8261A. The GW-Instek bench multimeters seem all to be based on different platforms. The main CPU is a Freescale (ex-Motorola) Coldfire MCF52258 processor surround by a few beefy Lattice CPLD's. This explains the S19 records from I also was a bit surprised.

The meter is still recognized in the device manager as a "multimeter" and still pops up in Windows as a removable disk all be it with a "scan this drive for errors" message. So some of the internal firmware is still present and doing its job. Scanning this "removable drive" results in "no errors found". I can still perform the update procedure.

Some pictures of its internals.... Its Voltage reference is a MAX6325CPA DIP8 which is also used in Siglents' SDM3055 and Hanteks' HDM3065  (in a different package).

[coromonadalix]

mmm strange for the s19 files, i never consider them as a firmwares updates,  maybe you could try other GW instek branches / countries and try to explain them, the meter is now some paper weight 

the 8251  could be flashed and be recovered, this one seems a mystery,  unless its rebranded ??

there must be some recovery procedures ?? or other flash tools / files ?

for this model  i find nothing of interest on their site (im registered for free) , and some other GW xxx  meters do have bin / hex  fw files / and the needed tools ... 


and you do have the cal key
it was discussed here,   in this usb connector  on 2 pins  its an 100 ohms resistor if i recall


and on the picture,  there is a tact switch and a some jumper pins near the coldfire mcu, i wonder what they do ?? 


you say the device show as a drive,  with the cal key inserted at the right place   
if you put back the needed file 102  or  103 versions  and reboot ?    still nothing ?   

never do a repair or scandisk on theses types of errors   windows is a @$$@%@   because sometimes you may or could have different partitions / maybe some "nux" stuff and windows is not able to handle them properly


window did messed up some embedded board in the past because of that, i had  normal partitions and some "nux" ones too  and messed up them because i did a repair 

[maralb]

I do have the GDM-01 calibration key. The pushbutton seems to reset the CPU. There are also a few LED's around the CPU which are flashing in the same pattern all the time. It seems like it is restarting all the time; they stop when pushing the button and start flashing again after releasing it.

I also put a jumper cap already on the pins and repeat the flashing procedure with it installed but that shows no sign of a difference in the behaviour.
I tried to recover the device with V102 already without the desired result unfortunately.

Good call about the repair/scandisk activities by Windows. I did let it scan but the outcome in Windows was always the same: no errors found and I assume no changes made.

It is indeed a brick now which saddens me a bit because it was a nice instrument and paid good money for it. I have to take my loss I am afraid  :'(

[coromonadalix]

Q:  you have an 10 pins idc black connector, is it going to the serial port ??   or its an unconnected header seems to go to an analog device chip,  is it an rs232 transceiver

and 2 pins seems to go on 2x optocouplers ??


not sure if this connector is a console port of somekind ??  maybe you could search the ic pinout   maybe  you could see the boot process

for now the meter is partially alive, must be some boot corruption ?   and i see 2 eeproms around the coldfire mcu,  some of them could have gone bad in the programmation 


i would have played in this meter trying to get a console port   this mcu apparently has 3 uarts  ....

Do not despair, be patient,  maybe  someday you may be able to start it up ....     check  this  mcu "coldfire" devlopement boards,  maybe there is some infos or tricks who could be learned ??

[maralb]

I will monitor the RS232 ports to see if there is any activities on those. I don't expect much from that as I don't think there is a fancy O/S embedded to control the whole thing. But you never know. The flashing onboard LED's are trying to tell me something but I don't have any access to any information they can show.

There are indeed 2 24LC512 I^2C EEPROM's present close to the CPU. What contents could they have? User data? Configuration data? USB ID data? Calibration data?

There are also 2 connectors present, one 7p header and a 2x13 pin header. There are connections leading to the CPU at those. The continuity tester will be my friend.... Maybe I can access the CPU with my Elnec Programmer which supports this processor.

Looking at the whole update procedure it just feels odd. It starts already with the USB A to USB A cable (host to host). The Calibration Key.....just dragging a motorola s-record into a filemanager which is there in a few seconds and then the unit should be updated. You don't see an erase cycle, don't see a programming cycle, don't see a verify cycle. It just feels there is something missing in the whole procedure.

[coromonadalix]

This hard drive method is used on some devices ... i have an usb gpib device who do the same thing,  you see a drive, put content in it, and bam it's updated

BUT   you need a boot loader ... a boot system  who could be at a different place / memory address etc ... 

That's why i refered to you the development board based on theses coldfire mcu's, surely there will be some explanations ...


I think GW Instek do provide FW update,  but they dont seem to provide a way to repair "corrupted boot" or a way to recover some failed FW update / un bootable unit ?

Maybe  try once again talking to them and see if they have a repair facility,  other tools, infos on how to recover the unit 

one of the 2 eeproms could have some boot infos ??  and the other should have the calibration(s) stored there

i would try to do a rough sketch of the system,  see all the peripheral ic's around this coldfire ...  flash memory, sram  etc ...     

Sadly i dont see the part number very well on the pcb, and we dont see all of it,  to see if there is some transceivers as i wrote earlier, 

for sure  you need a way to program a few things to manufacture this pcb ??  the Lattice must act as an i/o  interface

[Fractal]

Hi mate,

Sorry to hear about your troubles;

I have just acquired one of these pups a couple weeks ago, bit of a weird find, but running jolly fine; got it stuck on 1.02 for now as it came with a missing calibration key

For being actually based in Taiwan, support has been pretty responsive to me with the calibration quotes and even a quote for a new calibration key for 20dollas

I also just got me a T48 eeprom programmer that I'm eager to get roi for lol, let me know if there's anything I can help you with; be it trying and facilitate communication with the Taipei HQ, or getting you a dump of any ram that could serve you

[maralb]

An update....

I managed to access the Coldfire controller by its Ez-Port interface with my Beeprog2 programmer. I could read the contents; there was still data present in the first block ($0 ~ $3400) but the adresses from $3400 ~ $7ffff were filled with FF....erased.

I compared this initial block with the V1.02 file I got from GW-Instek and they matched.

I was able to program the Colfire controller with the V1.03 file I got from GW-Instek. To my great joy the GDM8261A came to life again. The excitement was short lived however when I realized the multimeter wasn't responding to the front butttons. They sometimes responded short after powering up and I could measure a +5V voltage from my power supply if I was fast enough to reach the right setting after powering on the instrument. Then the instrument started to reset more often and now finally it ended up  stuck in a bootloop.

I programmed the instrument again with the V1.02 file but the result is the same. The display shows only this cycle after powering it on:

-all segments at the display light up
-GDM-8261A V1.02
-PARA02 - RECALL
-NO SAVE - RECALL
-PARA.DEF - RECALL
Then a beep and a restart with the same procedure

I assume the configuration data in one of the external serial EEPROMs is corrupted?!

At least I got some result but still not were I am hoping for     .....any ideas or anyone have similar experiences with GW-Instek benchmultimeters?

[coromonadalix]

mm   seem if there is an external eeprom, it got messed up too,  now the meter seems to need  some definition / parameters ...

hope someone can chime in to help with an eeprom dump

unless you have some problems around the cpu ?? supplys  etc ...   witch sound improbable since it was working before

[maralb]

Thank you. I will try to access the 2 24LC512 EEPROMs when time and my mood permits. It should be doable in-circuit when I keep the /Reset for the ColdFire controller active. I do have a few other ideas. I don't have much to loose on this and the fact I was able to access and program the controller with the Beeprog is already more as I expected. Maybe all this is helpfull for other GDM-8261A owners; there is not much info available about those on the web.

[maralb]

Well, I was finally able to recover my GW-Instek multimeter. A cracked 0805 100R SMD resistor was the culprit causing the bootloop.

I had to solder a few pins to some resistors in order to break out the necessary signals to the EzPort interface needed to program the ColdFire controller In-Circuit with my Beeprog2 programmer. When connecting wires to these pins one of the pins snapped off breaking one of the resistors in the proces. Replacing the resistor finally solved the bootloop problem and the instrument is in full working order again  . Phew... Oh, it is on V1.02 again and for the moment I will keep it like this....

For owners facing a bricked GDM-8261A....it is possible to recover your instrument. You can access the ColdFire controller by its EzPort interface, The only problem is to locate the necessary signals. These are not isolated at a connector but a bit scattered over the board as the signals are used for other purposes.

You will need the followong signals:

/RST_IN  -> Reset signal located at the 26 pin connector
/RCON-EZPCS -> accessable at a 4k7 (472) SMD resistor close to the onboard Reset Button (I soldered a pin to this resistor). Coldfire controller pin 10.
QSPIDI-EZPD -> accessable at a 100R (1000) SMD resistor under the metal cover also shielding the Voltage Reference. Coldfire Controller pin 24.
QSPIDO-EZPQ -> accesable at a 100R (1000) SMD resistor under the metal cover. Coldfire Controller pin 25.
QSPI_CLK-EZPCK -> accesable at a 100R (1000) SMD resistor under the metal cover. Coldfire Controller pin 26.

You can find the 100R resistors in a group just next to a 10uF electrolytic capacitor. I soldered pins to these resostors in order to access the signals (and broke one later  )

You also need to connect VDD and VSS to the programmer which I derived from the 26 pin connector. VDD is just monitored by the programmer, I powered the PCB external with +5V at the white connector next to the COM port connector. There is an onboard 3V3 regulator powering the ColdFire controller.

The Beeprog Programmer demands to initialize the EzPort Write Configuration Register in order to set the Flash Controller's internal clock. This depends on the clock frequency the controller is running at. This is 48MHz. An equation learns that the value for the Write Configuration Register is to be initialized with 0x4f

If everything is connected properly you should now be able to recover a bricked GDM-8261A bench multimeter. With the Beeprog programmer, you have the option to select the speed of the SPI bus; I set it to the slowest 100kHz due to the primitive wiring. You can Erase and Program the ColdFire controller over its entire range.

Maybe this helps other people. Don't hestitate to contact me if you need help recovering your instrument.

[coromonadalix]

kudos for your tenacity