I tried Martins FW 6.00.2423.059 on the 4410 and it loads OK. So firmware for 4410 and 4510 is the same as expected.
Model will be stored somewhere in flash or EEPROM, question is it easier to change that string or mod the FW to select that model number.
Hi,
How easy is it to update?
Now that I know how to do it, it went quickly...
I received the update tool with the new firmware and copied the folder to the desktop.
Changing baud to 19200 on the instrument or in device manager, won't really do anything. Updated your instructions:
For Windows 10 (ignore for XP):
- Copy MSCOMM32.OCX and pasted it into the updatetool folder.
- Pressed the Windows key+X, then selected Powershell (Administrator).
- Changed to the updatetool folder and entered "regsvr32 MSCOMM.OCX".
- Powershell terminated.
- With ET4510/4410 powered off
- Start update tool exe, browse for .hex file, select COM port.
- Click the button "? ? ? ?" and then switch on the ET4510.
- The flash process starts, after 100% the ET4510 restarts itself
- If the flash process stuck at 0% for more than 30s, turn off the ET4510, restart the program, and try again (so far it always took two tries for me and worked on second attempt)
edit: if you look under the SCPI commands in the firmware you'll see
for DISP: "MEASUREMENT, COMPSET, SYSTEM" and then just under that all the model numbers, 4401, 4402, 4410, 4510... (0x8015698).
Maybe a coincidence or maybe there is a scpi command to set the model number.
Hi,
Thanks for the correction, maybe I'll add a picture gallery, as james38 already did in part.
(..)So firmware for 4410 and 4510 is the same as expected.
Model will be stored somewhere in flash or EEPROM, question is it easier to change that string or mod the FW to select that model number.
Thanks that you have already tested it, then I don't need to do it anymore, or maybe I should upgrade the ET4410 with this newer firmware anyway.
OK...
So one firmware for both models.
And very probably for all frequency types, whether 10kHz or 100Khz.
But it is only one chip, so the information must have been written to the chip somehow "before" or separately, in terms of who I am and which measuring frequency I output the highest.
Or there are two MCUs in the device, to make sure that this information is only available on the chip in the front board, I will swap the fronts with each other.
Interesting thing.
I've seen some switch/case statement in the firmware, which branched to several model types. The input of that switch seemed to be in some memory area, which could be SRAM, according to the data sheet. But i did not find where the information was written into that memory.
I assume we have some flash-memory-area, to which things like model type and serial number are written. This is why I would like to know more about the communication of the update process. Maybe one can write to other flash ranges in a similar way. I would also appreciate very much if we could also read the flash.
I tried this with PuTTy, but it didn't work because the COM port was already occupied by the upgrade tool.
Conversely, PuTTy ran first, but the upgrade tool did nothing.
Let me swap the front panels next weekend, then we'll know more.
I also have another idea that I want to follow up on this weekend.
I also have another idea that I want to follow up on this weekend.
Will you tell us in advance, or after trying it out? If you have a logic analyzer, you could also have a look at the communication between the two boards.
After trying....Could be a too stupid idea.
I've seen some switch/case statement in the firmware, which branched to several model types. The input of that switch seemed to be in some memory area, which could be SRAM, according to the data sheet. But i did not find where the information was written into that memory.
I assume we have some flash-memory-area, to which things like model type and serial number are written. This is why I would like to know more about the communication of the update process. Maybe one can write to other flash ranges in a similar way. I would also appreciate very much if we could also read the flash.
Here is a portmon capture of the upload: https://easyupload.io/33ror1.
It doesn't start until several hundred lines in.
edit: wrong settings I will recapture
Thank you!
Here, it starts to get interesting. The Bootloader answers with its version number:
14298 0.00000698 ET4410_upgrade. IRP_MJ_READ Serial1 SUCCESS Length 122:
............Bootloader Ver:3.00....----------------------..[1]..
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.
Later on, it seems to send hex packages with addresses. Looks promising, that there is a good chance to upload a patched firmware.
Interesting: In the serial transfer, I see less than 80kB written to the device and this seems to be in hex, so probably less than 40kB, while the firmware is abut 211kB as binary.
Excuse my ignorance but is there any danger of messing up any calibration by updating the firmware?
I can't imagine that.
I assume that the values are stored in the chip on the signal board and that only the program from the chip in the front panel is updated.
Excuse my ignorance but is there any danger of messing up any calibration by updating the firmware?
I would also consider the risk as minor. The update-firmware and the tool are provided by the manufacturer. The open/short calibration can be done by the user and I would assume, that there is not much more device-specific calibration, because the last mV or Hz will not count for a device of that category.
I tried to update quite a few times and I've failed miserably... FWIW, my PC has a serial port so I connected the LCR via a RS232 cable that came with some siglent gear.
Can you please clarify what you mean by "- Changed to the updatetool folder and entered "regsvr32 MSCOMM.OCX"."
In a hour or two, I could show how this is to be done.
Interesting: In the serial transfer, I see less than 80kB written to the device and this seems to be in hex, so probably less than 40kB, while the firmware is abut 211kB as binary.
The boot-loader seems to interpret the lines from the intel-hex file by itself. But not all lines from the hex-files can be found in the log. I guess the log is just not complete and 80% of the communication may be lost. I think it will not be worth to visualize what is missing, because I don't expect systematic blocks there, but a rather random distribution.
I tried to update quite a few times and I've failed miserably... FWIW, my PC has a serial port so I connected the LCR via a RS232 cable that came with some siglent gear.
Can you please clarify what you mean by "- Changed to the updatetool folder and entered "regsvr32 MSCOMM.OCX"."
Are you roughly familiar with using a shell, in which you change directories by typing commands like
cd?
It is also helpful to use the other tool, which controls the instrument over the serial line, to check if the serial communication is working with your serial cable.
Well, the problem is that I get an error when I try to register the .ocx.
I have tried both the one that is included in the folder as well as the one from the ocxme.com.
I have pasted the .ocx inside the system32 folder but it doesn't wanna register it...
FWIW, windows10 on an offline PC
What error message do you get?
Did you try it it the directory with the .exe and the .hex?
Did you really make sure, that the shell you are running, has admin rights?
What error message do you get?
The module ".\mscomm32.ocx" failed to load
Mkae sure the binary is stored at the specific path or debug it to check for problems with the binary or dependet.DLL files.
The specific module could not be found.Did you try it it the directory with the .exe and the .hex?
Yes. I even tried by putting the .exe inside the system32 folder
Did you really make sure, that the shell you are running, has admin rights?
Indeed
Hmm, not easy. The mscomm32.ocx came with some other .ocx files. I don't know, if it depends on them. Maybe it is worth trying to register the others, before?
You could also try to specify the full path, not a relative one.