East Tester ET4410&ET4510 Desktop LCR Meter

[EEMax]

Did you have a chance to take a look at the source code of the updater yet?

[thephil]

I don't think, the updater tool implements any parsing of the hex files. I had analyzed the update procedure for the ET54xx loads that seem to use a similar mechanism and implemented my own updater tool.  For that device, you only trigger the bootloader, select the first option (upload) and then transmit the hex file. All parsing and programming is done by the bootloader.

I am planing to write an updater for the ET44xx, so if you have a little patience, that should be coming soon.

[w.v.s.]

Did you have a chance to take a look at the source code of the updater yet?

No, but I've seen the communication between the pc and the device during the update process and it looked rather straight simple, similar to what thephil described.

[EEMax]

Did you have a chance to take a look at the source code of the updater yet?

No, but I've seen the communication between the pc and the device during the update process and it looked rather straight simple, similar to what thephil described.

I believe the simple "streamer" approach suggested by thephil may be too brittle for this hardware. To build a truly reliable updater, it is necessary to address three critical risks:

1. The "Record Type 05" Trap: The latest firmware (v6.00.2522.079) includes a Type 05 record (Start Linear Address). Legacy STM32 bootloaders often only support Type 00 (Data) and Type 01 (EOF). If the internal parser encounters an unknown Type 05, it may abort the flash. The tool must filter out the :04000005... line, as it is redundant for ARM Cortex-M hardware.

2. Buffer Overflow & Flash Latency: 115,200 baud transmits data faster than an STM32 can erase and write to Flash memory. Without flow control, the UART buffer will overflow, leading to firmware corruption. It is essential to implement a Wait-for-Echo/ACK loop or, at minimum, a 15–20ms inter-line delay to allow the MCU to complete its write cycle.

3. Pre-Flight Checksums: The HEX file should not be trusted blindly. The updater must locally verify all Intel HEX checksums before starting the transfer. If the file on disk is corrupt, the tool should refuse to initiate the flash.

Improving Recovery Logic:
Instead of a manual trigger, the implementation should include a "Bricked Device Recovery" button that automatically cycles through baud rates (9600, 57600, 115200) while repeatedly sending the trigger byte until the meter responds. Using a logic analyzer would be valuable to confirm if the meter returns a specific NAK or error code the moment it encounters that Type 05 record.

That is my analysis, of course there may be still room for improvement.

[thephil]

I hate Windows! Yesterday I tried to get that damn tool up and running so that I can sniff the communication, but for the life of me, I can't get it to work in my virtual Win10 machine.

@w.v.s  how did you install the mscomm driver? I suspect that's my problem...
Or alternatively: it sounds like you already did record the communication. If that is correct, I'd love to have the recording...

I have tried to use both USB and RS232 and in both cases I can see the respective com-port without issue.

I can start the updater binary as Admin, select the hex file and press the button under the "100" field. I then get some cryptic Message box, but power-cycling the meter does not do anything...

EDIT: never mind. I think I got it to work following the instructions by Martin72 much further up this thread. I already had a first look at the process and it seems that the procedure is almost identical to the one for the ET54xx electronic loads. I'll keep tinkering and will report back when I'm confident enough.
BTW: my ET4410 came with V6.00.2232.019 and it is quite possible that it is not compatible with the latest version. So if anyone has an older hex files, I'd be very happy to hear about it.

[jheissjr]

ET44xx has a version newer than V6.00.2232.019 if the rev is helpful.

[thephil]

ET44xx has a version newer than V6.00.2232.019 if the rev is helpful.

Do you have the hex file for it?

[jheissjr]

Sorry I don't have a hex file for it. The ET4410 was delivered with V6.00.2423.059. I wonder if there is a newer version because the ET4410 delivered with V6.00.2423.059 was manufactured 13 months ago.

[w.v.s.]

I came across two V6 files from 2024 and one V1 file from 2022 for a older (non compatible) hardware in this thread.

[w.v.s.]

@w.v.s  how did you install the mscomm driver? I suspect that's my problem...

Since I am less used to Windows, and it being not such a nice OS,  , I took at bit longer to get the firmware setup software talking in Windows ( 8 ). This is what I did:
Copied the MSCOMM32.OCX from the archive that came with the firmware into the same directory as the firmware setup program.
Then, started the PowerShell with admin rights and then typed:

Code: [Select]

C:\windows\system32\regsvr32.exe .\MSCOMM32.OCX
I closed the window telling about the registration success.
Then I started the setup-program also with admin rights. It then sent out the described messages over my USB-RS232-Interface cable.

[thephil]

I came across two V6 files from 2024 and one V1 file from 2022 for a older (non compatible) hardware in this thread.

Excellent! Could you provide the 2022 file, please?

Edit: misread that. I'll search the thread.

But I guess, I'll need a V6 from around that time, too...

[w.v.s.]

But I guess, I'll need a V6 from around that time, too...

I don't think so. Martin72 has upgraded from a 2021 V6 version to a 2024 V6 version, too. So I guess any valid V6 file should do.

Here you can see that everything is in Chinese, including the "strange characters" in the tool itself.
Somehow this does not work with Windows 10, with the complete language pack usage:
https://www.eevblog.com/forum/testgear/east-tester-et4410-desktop-lcr-meter/msg5524615/#msg5524615

Thanks to the post, however, I have also discovered that the new firmware is installed on my ET4410:

Contrary to the version in the file name, the correct version that is inside is: V6.00.2405.039

My version before flashing(Unit bought 07/2023):
V6.00.2136.018
So it worked after all.

[w.v.s.]

@w.v.s 
Or alternatively: it sounds like you already did record the communication. If that is correct, I'd love to have the recording...

Did not do that by myself, but thm_w was so friendly to do so. You will find the attachment when you go to his original message, which I quote here. My impression is that the log is not complete, but gives a pretty clear picture.

The log is clipped and non-printing characters are shown as '.'. But it seems that the software selects option one from the bootloader menue. I'm afraid the Bootloader will talk Chinese, too.

Thats my fault, you have to setup portmon settings first: https://www.mathworks.com/matlabcentral/answers/103079-how-can-i-use-portmon-to-monitor-my-serial-port
If you want the full capture, I think its everything, in hex its attached.

It is in chinese, translation below

Code: [Select]

杭州中创 - Hangzhou Zhongchuang (easttester)
Bootloader Ver:3.00

----------------------
[1]下载程序  - Download the program
[2]运行程序 - Run the program
[?]帮助      - Help (just shows this screen)
----------------------
Flash is deleted after choosing 1 which is why we see black screen:

Code: [Select]

删除Flash... Deleting Flash
删除完成!  Deletion Complete
准备接收文件... Ready to receive files
--hex transferred here--
下载成功! Download successful


[thephil]

Yes, that is exactly what the ET5410A+ electronic loads do as well. Yesterday evening, I made quite some progress adapting my updater tool for the loads to the ET4410. The basic process is identical, but the ET44xx is quite a bit more picky about the file transfer than its ET54xx sibling, so I'm still working on that. The ET54xx is happy to be fed the entire file in one big chunk and starts programming only after the files has been received, while I believe the ET44xx wants so be fed in smaller pieces and possibly programs as it received data but I still have to confirm that (and unbrick my device in the process ;-) ).

I'll report back when i'm done.

[thephil]

I don't think so. Martin72 has upgraded from a 2021 V6 version to a 2024 V6 version, too. So I guess any valid V6 file should do.

Thanks! Good to know, because at the moment, I am not sure if the device is bricked because the hex file is incompatible with my device or because my updater tool is not working correctly, yet. I'll try with the manufacturers' tool, again.

[thephil]

Short update:

I have been trying to run the original updater tool. I have gotten it to start on Win10 in a VM and it will trigger the bootloader and show the menu. However, after clicking the "Upload" button, the program just hangs and seems not to select "[1] Upload". At least I don't see the usual messages about clearing flash and ready for upload. And after that point there is not further traffic on the COM port.

So I tried on a real Windows computer (Win11): This time, I get an error message after clicking upload. I successfully registered MSCOMM32.OCX but it won't accept upload. Unfortunately, I cannot copy the error message so I could not translate it.  Grrrrrrrr!

So I am a little stuck with respect to recording the traffic. I got the part until the full bootloader menu shows but I knew that already...

What version of Windows did you guys get the tool to work on?

[w.v.s.]

Did you try wine? There was one report of success with that. There was also a discussion on disabling DEP on win... machines.

[thephil]

No, I haven't tried that yet. But I found the full traffic log that `thw_m` created and went with that. I think I have implemented the entire protocol now. At the same time, I believe I managed to compromise something. I.e. I get a buffer overflow after sending the second row of the hexfile. Here is a log of running my tool:

Code: [Select]

❯ ./et44fwupdater.py images/ET44_V6.00.2522.079.hex
Sending magic number. Please turn on the device now.
    .     
Waiting for bootloader
> 杭州中创
> Bootloader Ver:3.00
> ----------------------
> [1]下载程序
> [2]运行程序
> [?]帮助
> ----------------------
Selecting: [1] File Upload.
> 删除Flash...
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> 删除完成!
> 准备接收文件...
Uploading 'images/ET44_V6.00.2522.079.hex': 612664 bytes
Progress: 60/612664 bytes 0%
>

> *** 空间溢出!
Overflow in line: 2


I'll keep investigating over the easter weekend. Seems appropriate for an East tester device 

[w.v.s.]

Try and wait 100ms after sending each line and read back the answer.

[thephil]

I have tried waiting up to a second and still get that.

At some point I had manages to send more data before seeing the overflow. Not sure, what is going on.

[jheissjr]

The Google translate app on Android and Apple translates text in images. Take a picture of the message next time with the translation app and it will translate the Chinese to English.

[thephil]

The Google translate app on Android and Apple translates text in images. Take a picture of the message next time with the translation app and it will translate the Chinese to English.

Good point. Will try that if I give the Windows tool another chance. I'm curious how well it will work, because I never bothered to change the locale to Chinese. Why? LLMs are really good at translating garbled output (lost in encoding) to English. That  was very helpful...

[jheissjr]

Attached is V6.00.2611.089 for the pictured ET44xx hardware revision. The firmware is current as of April 1, 2026. Also attached is the firmware update tool.

[cbelcher2020]

Short update:

What version of Windows did you guys get the tool to work on?

I was on my laptop, so that would be Windows 11.  I can get you a build number if that helps?
Took some pretty exhaustive note during the procedure, didn't feel like going through that 1/2 day exercise again.

More than happy to post.

[cbelcher2020]

Looks like yours is a little more jacked up then mine.  I didn't experience any of the output you provided.