EEVblog Electronics Community Forum
Electronics => Microcontrollers => Topic started by: onesystem on October 31, 2023, 01:26:42 am
-
Background: U1273AX has OLED display that is dying. OLED display uses SSD1303 controller, EOL of which was in 2010. Current OLEDs of same parameters use SSD1309 controller, command set of which is slightly different. Direct replacement results in mirror inverted image plus shift of the display by two columns.
Here is the translated to English German document (I Google translated it) that basically explains the problem:
https://drive.proton.me/urls/3PFD4JFY74#9A1wSB7HVweb
Instead of adding circuitry I thought if it is possible at all to adjust the firmware to the U1273AX directly.
Keysight provides firmware updates for the multimeter. Here is the latest 3.03 version:
https://drive.proton.me/urls/N55QYAYX80#j24y3g6IIvZT
Inside it there is a binary file u1273ax_v303.ag which is uploaded to the D78F0547 during an update.
Thankfully there is an awesome soul who wrote a decompiler for this series of microcontrollers:
https://github.com/mnaberez/k0dasm
It is written to work with ASxxxx Cross Assembler: https://shop-pdp.net/ashtml/asxget.php
I had to update two files command.py and symbols.py with command sets and pinouts that correspond with D78F0547
Here are the links to them:
https://drive.proton.me/urls/SERRTAHHZM#XDrd7wwvzOkc
https://drive.proton.me/urls/NXZ45SNNMW#aJBO1dpW3PZv
Here is the hardware manual for 78K0 series and also programming document:
https://drive.proton.me/urls/SF51ZB1RF4#R0M7AdtgC0SV
https://drive.proton.me/urls/G0F5REFDBC#tp38ti26zHNf
Here is the datasheet for ssd1303 controller:
https://drive.proton.me/urls/VGWZK8FXJR#RXWok2fGv61F
Here is the datasheet for ssd1309 controller:
https://drive.proton.me/urls/F8B3KZF1G8#x5yEJGvQsdlz
I do not know assembly. Can someone who understands all this please at least encourage me to continue or tell me this is an impossible task, and why. It of course would be awesome if someone is willing to help to adjust firmware to be compatible with SSD1309, but I cannot hope it will happen.
I do not want to spend many hours of monkeying around with assembly and understanding all of the ins and outs of controllers just to find out down the road that it is impossible to adjust this firmware successfully.
How I plan to upload the firmware - roll back existing 3.03 version to 3.01 on meter, then update it back to 3.03 but with edited code. Keysight allows rolling back this multimeter.
Additional info:
The D78F0547 is communicating to the screen via SPI
The following pins are related to OLED SSD1303 PCB:
pin func
============================================
58 P57 (Port 5) 0xFF05
57 P56 (Port 5) 0xFF05
56 P55 (Port 5) 0xFF05
55 P54 (Port 5) 0xFF05
45 P53 (Port 5) 0xFF05
44 P52 (Port 5) 0xFF05
43 P51 (Port 5) 0xFF05
42 P50 (Port 5) 0xFF05
69 P130 (Port 13) 0xFF0D
75 P145/STB0 Port 14 / Serial strobe (Serial interface CSIA0) 0xFF0E
76 P144/SOA0 Port 14 / Serial data output (Serial interface CSIA0) 0xFF0E
77 P143/SIA0 Port 14 / Serial data input (Serial interface CSIA0) 0xFF0E
============================================
Thank you for your attention!
-
How to replace the Agilent / Keysight OLED display for just $10!
- Buy the display: Aliexpress (https://www.aliexpress.com/item/1005005701373912.html) (Or search for "SSD1309 8080").
[attachimg=1 width=320]
- You might need to install the Prolific drivers. If getting code 10, install the attached drivers.
- Make sure Windows is using them: Open the Device Manager, check those under USB devices/USB serial port and COM ports/USB serial port, replace driver if needed.
- Don't attempt loading a firmware from another model, it'll brick the device! (Not irreversible, see Recovering section below)
Agilent / Keysight U1273A / U1273AX
If your device has firmware version v4.xx it will work straight away, no firmware modification is required!
- Confirmed working!
- Download and extract U1273A(X)_V303_mod.zip.
- Run the updater.
- Original installers from Keysight: U1273A (https://www.keysight.com/zz/en/lib/software-detail/instrument-firmware-software/firmware-update-for-u1273a-handheld-digital-multimeter-2371043.html), U1273AX (https://www.keysight.com/zz/en/lib/software-detail/instrument-firmware-software/firmware-update-for-u1273ax-handheld-digital-multimeter-2683029.html) .
Must be v3.01, newer version will check the current firmware and block the update if already in the latest version!
Just change the firmware name to U1273A(X)_V301.AG. (A or AX).
Agilent / Keysight U1253A
- Confirmed working! - 08/13/24: Capacitance bug fixed.
- Download and unpack Agilent U1253A Firmware Update V120_mod.zip.
- Run the updater.
Agilent / Keysight U1253B
- Confirmed working! - 08/13/24: Capacitance bug fixed.
- Same bootloader routines as 1253A, so same mod, should work.
- Download and extract U1253B_V304_1123a_mod.zip.
- Run the updater.
Reverse engineering details
All the bits & low-level details can be found few posts below (https://www.eevblog.com/forum/microcontrollers/8-bit-78k0-d78f0547-help-with-firmware-modification/msg5284399/#msg5284399).
Recovery
If something goes wrong, it's pretty easy to recover using a usb-serial converter, read the messages starting here (https://www.eevblog.com/forum/microcontrollers/8-bit-78k0-d78f0547-help-with-firmware-modification/msg5287942/#msg5287942).
-
Looks like the column shift by +2 is here:
ROM:4538 movw MUL_B, AX
ROM:453A mov X, #80h
ROM:453C call !MUL ; :AX*MUL_B
ROM:453F movw HL, AX
ROM:4540 add A, #02h ; <<<<<<<<<< add 2 to start addr
ROM:4542 movw HL, AX
ROM:4543 movw AX, #0080h
ROM:4546 push AX
ROM:4547 movw DE, #I2CBuf80
ROM:454A push DE
ROM:454B movw AX, HL
ROM:454C call !I2CSend
Edit: @DavidAlfa: thanks, man, I've mapped most of the I2C-related lower level stuff just to find out that firmware talks to two addresses: A0 (EEPROM ?) and 90 (LM75 ?), then read entire thread again and found that only ref to I2C is your last message, OP never mentioned it :-DD
-
To anyone who is visiting this thread: DavidAlfa and I have cleaned up the R&D process, so there are no now useless back and forth for many many pages of trials and errors.
You can see in the post #1 original question and request.
In post # 2 is a summary of all the firmware discoveries that have been made by DavidAlfa and also assisted by abyrvalg.
For the later part of firmware modification abyrvalg was not involved and also he has not visited this thread for a while, so his messages are still here showing some of the R&D that was done.
I also reached out to a couple of places on other trheads on eevblog where people are directly wondering what to do with their dim/dying screens and gave a quick summary with links to here for reference.
I hope this work will make life easier for a lot of us who have the same meter!
Maybe similar patching can be done with other Agilent/Keysight meters with an OLED screen if the original OLED is hard to come by.
-
It looks like the flash is divided into two areas:
0000-3000 - bootloader
3000-end - app
App reuses bootloader functions (including those two display write ones), bootloader never calls anything above 3000.
I think the bootloader is never updated (it would need to overwrite itself somehow otherwise, but there is nothing like copy some code to RAM and run from there).
-
You don’t need to extract anything. The .AG file is a full flash image, including the bootloader, which is just gets skipped during flashing. You don’t need to overwrite the bootloader to achieve your things, those patches by DavidAlfa destroying display write functions were just for testing. What you need is to find display control calls from the app area and patch them, not the bootloader (unless some bootloader display functions sending wrong commands are reused by the app).
BTW, that “add 9A” ubfuscation is not add but xor (can be seen in bootloader).
-
So we might be able to redirect all the oled calls to a empty memory address, and write our own routine there, there's a big empty area filled with 0xFF.
Yes, even more, instead of identifying/patching all "wrong" commands (there are many C8 writes, some of them are not immediate values, but are taken from var at E309 initialized earlier) I'd just do a dumb search&replace of "call DispWriteCmd" (9A 68 0A) to some "call DispWriteCmdProxy" in an empty area, which would replace C8 arg with C0 and call the original func.
-
Ahh, cmd 81 wants a second command cycle? I see now, so my patch is wrong. Removed.
-
So there are no C8 commands sent at all, the InitDisplay at 0994 sends C0 (direct scan) and A0 (first seg is 0) - no flip, no shift, what are we solving here? :-//
Let the OP buy and mount some real display, see what would happen, then fix (if there will be anything to fix).
If something goes wrong, we can proxy the InitDisplay call from the app area (it is at 303C) to call the original func, then write additional commands flipping/remapping something.
-
Another patch for the future:
- part of DisplayInit containing "interesting" commands is copied to 7F60+ (entire func doesn't fit there)
- added a jump to func tail in boot
- app's call DisplayInit redirected to 7F60
- the segment mapping cmd (A0 now) is at 7FC7 (replace with A1 to shift by 2)
- the scan direction cmd (C0 now) is at 7FCD (replace with C8 to flip)
-
The redirection is already done in my patch, just change 7FC7/7FCD to introduce shift/flip. I didn’t wanted to send additional commands after the cmd AF (turn on) is sent, thus the function transplantation idea.
-
Here we go, all 4 combinations of flip and shift
-
Great! So let's wait for the new display to see what exactly we need to fix. We have a proof that we can do it at least.
-
It was a great cooperative job, see you both part 2 :)
-
THIS IS AMAZING! You are a genius!
Now this is the best meter ever, with custom imaging!
For my screen I had to:
- make 128x64px as monochrome BMP
- using coverter you referenced, https://javl.github.io/image2cpp/
- Load the bmp
- Tick "invert image colors"
- Tick "Flip image vertically"
- Draw mode: vertical - 1 bit per pixel
- Click generate code
- download as binary
- Fix the nibble ordering using your program
- Paste the file into FW
-
Well done guys, this is the best fix yet for this dmm!
I need to buy one of these meters now you've made them a bit future proof in such an elegant way.
[although U1272A is still my favourite]
-
Reverse engineering details in the U1253A / U1253B / U1273A / U1273AX firmware
» Binary format «
This part only applies for U1253B, U1273A and U1273AX updaters, the binary extracted from the U1253A is already reversed.
The updater only checks the file size, there isn't any kind of checksum, so we can modify it freely.
The .AG file is byte-reversed and nibble-swapped.
The first bytes:
A0 13 00 00 03 7F 06 7F
Are the actually the last bytes of the firmware:
F7 60 F7 30 00 00 31 0A
A tool was writen to perform this task: (Attached, including the sources).
Usage is as follows:
tool.exe [input] [output] [xor]
This tool is compatible with the .AG firmware file of Agilent/Keysight U1253B, U1273A(X) and maybe others.
It reverses the byte order and swaps the nibbles, optionally applying a XOR value.
The output will be the original firmware bytes, ready for modifying or disassembling.
Once modified, run the tool again to convert it back to the original format, it'll be ready for flashing.
XOR option is optional and only for research purposes, not required to reverse the original .AG firmware file.
XOR value must written in hex representation, like 0x9A.
Examples: tool.exe input.bin output.bin
tool.exe input.bin output.bin 0x9A
» Updater format «
This part only applies for U1253B, U1273A and U1273AX updaters.
It's not required to get your hands dirty with the updater, just for documenting purposes.
The updater reverses the bytes and nibbles back to normal when sending the firmware to the DMM, but also XORs the data with 0x9A.
Each packet seems to be 1024 firmware bytes + 2 bytes checksum.
First 32 bytes captured data from the updater communication:
3A 89 9A 9A 99 E5 9C E5 93 E5 96 E5 95 E5 88 E5
8F E5 82 E5 53 91 3F 91 81 E5 84 E5 BB E5 BE E5
Last 32 bytes of original .ag file:
F7 42 F7 12 F7 E1 F7 B1 B0 5A B0 9C F7 81 F7 51
F7 21 F7 F0 F7 C0 F7 90 F7 60 F7 30 00 00 31 0A
Reverse bytes and perform nibble swap:
A0 13 00 00 03 7F 06 7F 09 7F 0C 7F 0F 7F 12 7F
15 7F 18 7F C9 0B A5 0B 1B 7F 1E 7F 21 7F 24 7F
XOR everything with 0x9A, matching updater data: (This detail was essential to later decode the U1253A firmware!)
3A 89 9A 9A 99 E5 9C E5 93 E5 96 E5 95 E5 88 E5
8F E5 82 E5 53 91 3F 91 81 E5 84 E5 BB E5 BE E5
No further investigation was performed about the bootloader protocol or packet checksums, as this was not required for the firmware modification.
» Firmware sections «
- Bootloader: 0x0000-0x2FFF.
- App: 0x3000-0x7FFFF, 0x8000-0xBFFF(*).
(*) Flash is banked, so depending on the bank register, 0x8000-0xBFFF is mapped to 6 different flash areas:
- Bank 0: 0x08000-0x0BFFF
- Bank 1: 0x0C000-0x0FFFF
- Bank 2: 0x10000-0x13FFF
- Bank 3: 0x14000-0x17FFF
- Bank 4: 0x18000-0x1BFFF
- Bank 5: 0x1C000-0x1FFFF
No disassembler supporting 78K0 architecture and banked flash was found.
Thus, most of the work was performed analyzing the common area (0x0000-0x7FFF) and bank 0 (0x8000-0xBFFF).
» Display replacement «
- The difference is not the command set, but the display fabrication.
- The panel might be wired "backwards", showing a mirrored picture.
- The SSD1306/SSD1309 controller supports 132x64 resolution, but:
- Depending on the manufacturer, the first pixel column in 128x64 diplays is connected to controller column 0 or 2.
- The original displays uses X-offset=2, while the ones found in aliexpress seem to use X-offset=0.
- This is what causes the weird vertical line when replacing the screen, and the image being slighly shifted.
- Thus, firmware modification is needed to overcome all of this.
» Modification «
The original .ag file must be reversed with the tool to work with k0dasm (Only for .AG firmwares, doesn't apply for U1253A).
tool.exe U1273AX_V303.AG fw.bin
Once decoded, it can be partially disassembled after slightly modifying K0dasm (Attached).
k0dasm fw.bin > disassembled.txt
Useful links:
- 78K0 instruction manual (https://www.renesas.com/us/en/document/mah/78k0-series-instructions).
- Very useful assembler example in k0dasm repo: testprog.asm (https://github.com/mnaberez/k0dasm/blob/main/k0dasm/tests/end_to_end/testprog.asm).
With all this, the essential routines were identified:
call pattern:
send_data: sub_0a5d 9a 5d 0a
send_cmd: sub_0a68 9a 68 0a
oled_init: sub_0994 9a 94 09
oled_draw: sub_0ac2 9a c2 0a (Also calling sub_0b20)
oled_pos: sub_0b20 9a 20 0b
The mcu only updates the APP section, so program under 0x3000 cannot be modified.
Thus, new functions were made and placed in empty areas, replacing any calls to the functions in the bootloader with the new ones.
- Display init: sub_7f60, allowing custom X/Y flip (Credits: abyrvalg (https://www.eevblog.com/forum/microcontrollers/8-bit-78k0-d78f0547-help-with-firmware-modification/msg5152500/#msg5152500)).
sub_7f60:
clr1 pm1.0 ;7f60 71 0b 21 <<<--- Same as original function
clr1 pm1.1 ;7f63 71 1b 21
mov pu12,#0x00 ;7f66 13 3c 00
clr1 p1.0 ;7f69 0b 01
clr1 p1.1 ;7f6b 1b 01
mov pm5,#0x00 ;7f6d 13 25 00
mov pu5,#0x00 ;7f70 13 35 00
mov p5,#0x00 ;7f73 11 05 00
mov PM14,#0x02 ;7f76 13 2e 02
mov pu14,#0x02 ;7f79 13 3e 02
set1 P14.3 ;7f7c 3a 0e
set1 P14.4 ;7f7e 4a 0e
set1 P14.5 ;7f80 5a 0e
set1 P14.2 ;7f82 2a 0e
movw ax,#0x0064 ;7f84 10 64 00
call !sub_0946 ;7f87 9a 46 09
set1 P13.0 ;7f8a 0a 0d
clr1 P13.0 ;7f8c 0b 0d
movw ax,#0x000a ;7f8e 10 0a 00
call !sub_0946 ;7f91 9a 46 09
set1 P13.0 ;7f94 0a 0d
movw ax,#0x00ae ;7f96 10 ae 00
call !sub_0a68 ;7f99 9a 68 0a
movw ax,#0x00ad ;7f9c 10 ad 00
call !sub_0a68 ;7f9f 9a 68 0a
movw ax,#0x008a ;7fa2 10 8a 00
call !sub_0a68 ;7fa5 9a 68 0a
movw ax,#0x00a8 ;7fa8 10 a8 00
call !sub_0a68 ;7fab 9a 68 0a
movw ax,#0x003f ;7fae 10 3f 00
call !sub_0a68 ;7fb1 9a 68 0a
movw ax,#0x00d3 ;7fb4 10 d3 00
call !sub_0a68 ;7fb7 9a 68 0a
movw ax,#0x0000 ;7fba 10 00 00
call !sub_0a68 ;7fbd 9a 68 0a
movw ax,#0x0040 ;7fc0 10 40 00
call !sub_0a68 ;7fc3 9a 68 0a
movw ax,#0x00a1 ;7fc6 10 a1 00 <<<--- Segment remap cmd (Y-mirror)
call !sub_0a68 ;7fc9 9a 68 0a
movw ax,#0x00c0 ;7fcc 10 c0 00 <<<--- Scan direction cmd (X-mirror)
call !sub_0a68 ;7fcf 9a 68 0a
movw ax,#0x00a6 ;7fd2 10 a6 00
call !sub_0a68 ;7fd5 9a 68 0a
br !lab_0a0c ;7fd8 9b 0c 0a <<<--- Continue in original function
- Drawing: sub_7ec0 (Calling sub_7e80).
sub_7ec0:
push hl ;7ec0 b7 <<<--- Same as original function
push ax ;7ec1 b1
push ax ;7ec2 b1
movw ax,sp ;7ec3 89 1c
movw hl,ax ;7ec5 d6
mov a,[hl+0x0a] ;7ec6 ae 0a
inc a ;7ec8 41
mov [hl+0x0a],a ;7ec9 be 0a
mov x,#0x00 ;7ecb a0 00
xch a,x ;7ecd 30
push ax ;7ece b1
mov a,[hl+0x08] ;7ecf ae 08
mov x,#0x00 ;7ed1 a0 00
xch a,x ;7ed3 30
call !sub_7e80 ;7ed4 9a 80 7e <<<--- Call new oled position function
br !lab_0ad9 ;7ed7 9b d9 0a <<<--- Continue in original function
- Set position: sub_7e80, subtracting a value from the column value to fix the X-offset.
sub_7e80:
push hl ;7e80 b7 <<<--- Same as original function
push ax ;7e81 b1
movw ax,sp ;7e82 89 1c
movw hl,ax ;7e84 d6
mov a,[hl] ;7e85 87
xch a,x ;7e86 30
mov a,[hl+0x06] ;7e87 ae 06
movw hl,ax ;7e89 d6
mov a,#0xb0 ;7e8a a1 b0 <<<--- Row cmd
or a,l ;7e8c 61 6e
mov x,#0x00 ;7e8e a0 00
xch a,x ;7e90 30
call !sub_0a68 ;7e91 9a 68 0a <<<--- Send cmd
mov a,h ;7e94 67 <<<--- Move column value to reg A
cmp a,!mem_7e9e ;7e95 48 9e 7e <<<--- Compare with subtract value at 0x7e9e
bnc lab_7e9d ;7e98 9d 03 <<<--- If carry set, load A with subtract value so it becomes 0 when subtracting
mov a,!mem_7e9e ;7e9a 8e 9e 7e
lab_7e9d:
sub a,#0x02 ;7e9d 1d 02 <<<--- Subtract 2 to column value
mov h,a ;7e9f 77 <<<--- Update H reg for later use in lower column cmd
and a,#0x0f ;7ea0 5d 0f <<<--- Isolate lower column data
mov x,#0x00 ;7ea2 a0 00
xch a,x ;7ea4 30
call !sub_0a68 ;7ea5 9a 68 0a <<<--- Send cmd
mov a,h ;7ea8 67 <<<--- Move column value to reg A
ror a,1 ;7ea9 24 <<<--- Rotate 4 bits to the left to get higher column bits
ror a,1 ;7eaa 24
ror a,1 ;7eab 24
ror a,1 ;7eac 24
and a,#0x0f ;7ead 5d 0f <<<--- Isolate higher column data
or a,#0x10 ;7eaf 6d 10 <<<--- High column cnmd
mov x,#0x00 ;7eb1 a0 00
xch a,x ;7eb3 30
call !sub_0a68 ;7eb4 9a 68 0a <<<--- Send cmd
pop ax ;7eb7 b0
pop hl ;7eb8 b6
ret ;7eb9 af <<<--- Done, return
New functions:
call pattern:
oled_init: sub_7f60 9a 60 7f
oled_draw: sub_7ec0 9a c0 7e (Also calling sub_7e80)
oled_pos: sub_7e80 9a 80 7e
Hex bytes:
B7 B1 89 1C D6 87 30 AE 06 D6 A1 B0 61 6E A0 00 30 9A 68 0A 67 48 9E 7E 9D 03 8E 9E 7E 1D 02 77 5D 0F A0 00 30 9A 68 0A 67 24 24 24 24 5D 0F 6D 10 A0 00 30 9A 68 0A B0 B6 AF 00 00 00 00 00 00 B7 B1 B1 89 1C D6 AE 0A 41 BE 0A A0 00 30 B1 AE 08 A0 00 30 9A 80 7E 9B D9 0A
71 0B 21 71 1B 21 13 3C 00 0B 01 1B 01 13 25 00 13 35 00 11 05 00 13 2E 02 13 3E 02 3A 0E 4A 0E 5A 0E 2A 0E 10 64 00 9A 46 09 0A 0D 0B 0D 10 0A 00 9A 46 09 0A 0D 10 AE 00 9A 68 0A 10 AD 00 9A 68 0A 10 8A 00 9A 68 0A 10 A8 00 9A 68 0A 10 3F 00 9A 68 0A 10 D3 00 9A 68 0A 10 00 00 9A 68 0A 10 40 00 9A 68 0A 10 A1 00 9A 68 0A 10 C0 00 9A 68 0A 10 A6 00 9A 68 0A 9B 0C 0A
Because the entire firmware can't be disassembled, a manual pattern search and replace was performed:
- "9A 94 09" (call !sub_0994) -> "9A 60 7F" (call !sub_7f60)
- "9A 20 0B" (call !sub_0b20) -> "9A 80 7E" (call !sub_7e80)
- "9A C2 0A" (call !sub_0ac2) -> "9A C0 7E" (call !sub_7ec0)
Now, the user can easily patch the .AG file (Updater format, not reversed) using any hex editor like HxD to fix any difference in the screen:
Address Value Function
0x18032 0x0C / 0x8C X-mirror off / on
0x18038 0x0A / 0x1A Y-mirror off / on
0x18161 0x00-0xFF X-offset subtract value, nibble-swapped, so 0x00 / 0x10 / 0x20 for 0/-1/-2 pixel offset (Subtracted to the default 2 offset)
Remember this is hex, use a decimal to hexadecimal (https://www.rapidtables.com/convert/number/decimal-to-hex.html) converter.
For example, set 10 pixel X-offset: The number to put there is not 10 -> swap -> 0x01! 10=0x0A in hex, after swapping=0xA0.
The original firmware uses X-offset of 2, so applying a subtract value higher than 2 won't make any effect (Tested for underflow).
If for whatever reason, instead subtracting you want to increase the column address, patch as following:
0x18162 Replace [D1 E7 E9 E8 30 D9 E7 E9 84] with [D0 00 00 00 00 00 00 00 00].
Address Value Function
0x18167 0x00-0xFF X-offset add value, nibble-swapped, so 0x00 / 0x10 / 0x20 for 0/+1/+2 pixel offset (Added to the default 2 offset)
After modification, tool must be run again on the modified file to became ready to be flashed with the updater:
tool.exe fw_modded.AG U1273AX_V303.bin
Additionally, the boot logos were located and can be easily modified now.
This procedure is identical in v3.03 and v4.02 firmwares.
Offsets of the images in the .AG file (Updater format, not reversed):
- U1237AX logo: 0x8000-0x83FF
- KEYSIGHT screen: 0x8400-0x87FF
Make a 128x64px image in Paint or whatever, save as monochrome BMP.
Use this converter: https://javl.github.io/image2cpp/ (https://javl.github.io/image2cpp/)
- Load the bmp.
- Tick "Flip image vertically".
- Draw mode: vertical - 1 bit per pixel.
- If the image color appears inverted, tick "Invert image colors".
- Click generate code.
- Download as binary.
- Only for firmwares in .AG format: Fix the nibble and byte ordering: "tool.exe downloaded.bin fixed.bin"
- Open both the .ag firmware and fixed picture in HxD.
- In the image data, Right click over the data, click select All, Copy.
- Go to the FW data, Control+G, write this offset (hex):
- U1237AX logo: 8000
- KEYSIGHT screen: 8400
- Right click on that byte, "Paste writing". If you get a warning like "This operation will change the file size", you're doing it wrong.
- Save the file.
To load the modded firmware into the DMM, rename the modded file to "U1273AX_V303.AG", place it in the updater folder and run the updater.
I quickly analyzed v4.02 to find out it's very much the same thing, the addresses of the display functions and the boot pictures are the same.
But it seems be already doing the same as this mod, so no action required at all! Just replace the display with the one from the aliexpress!
cmp a,h ;0b2c 61 4f <<<--- Check if column is 0
bnc lab_0b31 ;0b2e 9d 01 <<<--- If not, decrease h
dec h ;0b30 57 <<<--- Otherwise skip
lab_0b31:
mov a,#0x00 ;0b31 a1 00
cmp a,h ;0b33 61 4f <<<--- (Again) Check if column is 0
bnc lab_0b38 ;0b35 9d 01 <<<--- If not, decrease h
dec h ;0b37 57 <<<--- Otherwise skip
movw ax,#0x00a1 ;09fa 10 a1 00 <<<--- Segment remap cmd (Y-mirror)
call !sub_0a68 ;09fd 9a 68 0a
movw ax,#0x00c0 ;0a00 10 c0 00 <<<--- Scan direction cmd (X-mirror)
call !sub_0a68 ;0a03 9a 68 0a
Specific for U1253B:
This write-up was made for the U1253B v3.04 firmware.
Original:
call pattern:
send_data: sub_05c6 9a c6 05
send_cmd: sub_05d1 9a d1 05
oled_init: sub_04f5 9a f5 04
oled_draw: sub_062c 9a 2c 06 (Also calling sub_068a)
oled_pos: sub_068a 9a 8a 06
New functions:
call pattern:
oled_init: sub_7f60 9a 60 7f
oled_pos: sub_7f70 9a 70 7f
oled_draw: sub_7faa 9a aa 7f (Also calling sub_7f70)
- Display init: sub_7f60:
sub_7f60:
call !sub_04f5 ;7f60 9a f5 04 <<<--- Call original function
movw ax,#0x00a1 ;7f63 10 a1 00 <<<--- Segment remap cmd (Y-mirror)
call !sub_05d1 ;7f66 9a d1 05 <<<--- Send cmd
movw ax,#0x00c0 ;7f69 10 c0 00 <<<--- Scan direction cmd (X-mirror)
call !sub_05d1 ;7f6c 9a d1 05 <<<--- Send cmd
ret ;7f6f af <<<--- Return
- Set position: sub_7f70:
sub_7f70:
push hl ;7f70 b7 <<<--- Same as original function
push ax ;7f71 b1
movw ax,sp ;7f72 89 1c
movw hl,ax ;7f74 d6
mov a,[hl] ;7f75 87
xch a,x ;7f76 30
mov a,[hl+0x06] ;7f77 ae 06
movw hl,ax ;7f79 d6
mov a,#0xb0 ;7f7a a1 b0 <<<--- Row cmd
or a,l ;7f7c 61 6e
mov x,#0x00 ;7f7e a0 00
xch a,x ;7f80 30
call !sub_05d1 ;7f81 9a d1 05 <<<--- Send cmd
mov a,h ;7f84 67 <<<--- Move column value to reg A
cmp a,!mem_7f8e ;7f85 48 8e 7f <<<--- Compare with subtract value at 0x7f8e
bnc lab_7f8d ;7f88 9d 03 <<<--- If carry set,
mov a,!mem_7f8e ;7f8a 8e 8e 7f <<<--- Load A with subtract value at 0x7f8e so it becomes 0 when subtracting
lab_7f8d:
sub a,#0x02 ;7f8d 1d 02 <<<--- Subtract 2 to column value
mov h,a ;7f8f 77 <<<--- Update H reg for later use in lower column cmd
and a,#0x0f ;7f90 5d 0f <<<--- Isolate lower column data
mov x,#0x00 ;7f92 a0 00
xch a,x ;7f94 30
call !sub_05d1 ;7f95 9a d1 05 <<<--- Send cmd
mov a,h ;7f98 67 <<<--- Move column value to reg A
ror a,1 ;7f99 24 <<<--- Rotate 4 bits to the left to get higher column bits
ror a,1 ;7f9a 24
ror a,1 ;7f9b 24
ror a,1 ;7f9c 24
and a,#0x0f ;7f9d 5d 0f <<<--- Isolate higher column data
or a,#0x10 ;7f9f 6d 10 <<<--- High column cmd
mov x,#0x00 ;7fa1 a0 00
xch a,x ;7fa3 30
call !sub_05d1 ;7fa4 9a d1 05 <<<--- Send cmd
pop ax ;7fa7 b0
pop hl ;7fa8 b6
ret ;7fa9 af <<<--- Done, return
- Drawing: sub_7faa:
sub_7faa:
push hl ;7faa b7 <<<--- Same as original function
push ax ;7fab b1
push ax ;7fac b1
movw ax,sp ;7fad 89 1c
movw hl,ax ;7faf d6
mov a,[hl+0x0a] ;7fb0 ae 0a
inc a ;7fb2 41
mov [hl+0x0a],a ;7fb3 be 0a
mov x,#0x00 ;7fb5 a0 00
xch a,x ;7fb7 30
push ax ;7fb8 b1
mov a,[hl+0x08] ;7fb9 ae 08
mov x,#0x00 ;7fbb a0 00
xch a,x ;7fbd 30
call !sub_7f70 ;7fbe 9a 70 7f <<<--- Call new oled position function
br !lab_0643 ;7fc1 9b 43 06 <<<--- Continue in original function
Hex bytes:
9A F5 04 10 A1 00 9A D1 05 10 C0 00 9A D1 05 AF B7 B1 89 1C D6 87 30 AE 06 D6 A1 B0 61 6E A0 00 30 9A D1 05 67 48 8E 7F 9D 03 8E 8E 7F 1D 02 77 5D 0F A0 00 30 9A D1 05 67 24 24 24 24 5D 0F 6D 10 A0 00 30 9A D1 05 B0 B6 AF B7 B1 B1 89 1C D6 AE 0A 41 BE 0A A0 00 30 B1 AE 08 A0 00 30 9A 70 7F 9B 43 06
Because the entire firmware can't be disassembled, a manual pattern search and replace was performed:
- INIT: "9A F5 04" (call !sub_04f5) -> "9A 60 7F" (call !sub_7f60)
- POSITION: "9A 8A 06" (call !sub_068a) -> "9A 70 7F" (call !sub_7f70)
- DRAW: "9A 2C 06" (call !sub_062c) -> "9A AA 7F" (call !sub_7faa)
Patching offsets: ( .AG file in updater format, not reversed)
Address Value Function
0x18095 0x0C / 0x8C X-mirror off / on
0x1809B 0x0A / 0x1A Y-mirror off / on
0x18071 0x00-0xFF X-offset subtract value, nibble-swapped, so 0x00 / 0x10 / 0x20 for 0/-1/-2 pixel offset (Subtracted to the default 2 offset)
If for whatever reason, instead subtracting you want to increase the column address, patch as following:
0x18072 Replace [D1 F7 E8 E8 30 D9 F7 E8 84] with [D0 00 00 00 00 00 00 00 00].
Address Value Function
0x18071 0x00-0xFF X-offset add value, nibble-swapped, so 0x00 / 0x10 / 0x20 for 0/+1/+2 pixel offset (Added to the default 2 offset)
The boot logos are placed in the same area as U1273A(X), same procedure applies.
Specific for U1253A:
This write-up was made for the U1253A v1.20 firmware.
The firmware is contained inside the updater .exe, it uses a completely different format, so a new tool was needed.
There's a RTF text file embedded in the executable containing Intel Hex format, it's clearly encoded.
:10 0000 A5 9F2CC0C03C4039403640334030402D40 45
:10 0010 A8 573D5A3D5545B144593D5C3D633D663D 0C
:10 0020 80 3D65306537652A6529652C6523652665 BC
:10 0030 98 0D4D704D774D7A4D794D7C4D634D664D 94
Checksum follows Intel Hex standard: Sum all bytes in (100000A59F2CC0C03C4039403640334030402D401 = 0xBB) and make 2-complement: 0x45.
These bytes will likely match this (From U1273A):
A0 13 FF FF 03 7F 06 7F 09 7F 0C 7F 0F 7F 12 7F
15 7F 18 7F 2D 07 09 07 1B 7F 1E 7F 21 7F 24 7F
27 7F 2A 7F 2D 7F 30 7F 33 7F 36 7F 39 7F 3C 7F
3F 7F 42 7F 45 7F 48 7F 4B 7F 4E 7F 51 7F 54 7F
It's XOR'red with [0x9A + 3rd field field]
:10 0000 A5 [ 9F2CC0C03C4039403640334030402D40 ] ^ [0x9A+0xA5] = [ A0 13 00 00 03 7F 06 7F 09 7F 0C 7F 0F 7F 12 7F ]
:10 0010 A8 [ 573D5A3D5545B144593D5C3D633D663D ] ^ [0x9A+0xA8] = [ 15 7F 18 7F C9 0B A5 0B 1B 7F 1E 7F 21 7F 24 7F ]
:10 0020 80 [ 3D65306537652A6529652C6523652665 ] ^ [0x9A+0x80] = [ 27 7F 2A 7F 2D 7F 30 7F 33 7F 36 7F 39 7F 3C 7F ]
:10 0030 98 [ 0D4D704D774D7A4D794D7C4D634D664D ] ^ [0x9A+0x98] = [ 3F 7F 42 7F 45 7F 48 7F 4B 7F 4E 7F 51 7F 54 7F ]
A tool was writen to extract/insert the firmware from/to the updater executable: (Attached, including the sources)
tool_U1253A.exe [ -e | -i ] [ input_file ] [ output_file ]
This tool extracts/inserts the firmware from/to the Agilent U1253A updater executable
Only tested with "Agilent U1253A Firmware Update V120.exe"!
-e: Extract the firmware from the updater executable into a file.
The output will be the original firmware bytes, ready for modifying or disassembling.
-i: Insert the firmware file into an existing updater executable.
Example: tool -e updater.exe firmware.bin (firmware.bin is created)
Example: tool -i firmware.bin updater.exe (firmware.bin is inserted into update.exe)
The routines were the same, and placed in the same addresses as the U1253B.
Modification was identical to the one in U1253B, however the extracted bin file is not reversed, and the .exe can't be directly patched, so the modifications are different:
Patching offsets: (Over the file extracted using the tool)
Address Value Function
0x7F6A 0xC0 / 0xC8 X-mirror off / on
0x7F64 0xA0 / 0xA1 Y-mirror off / on
0x7F8E 0x00-0xFF X-offset subtract value, 0x00 / 0x01 / 0x02 for 0/-1/-2 pixel offset (Subtracted to the default 2 offset)
If for whatever reason, instead subtracting you want to increase the column address, patch as following:
0x7F85 Replace [48 8E 7F 9D 03 8E 8E 7F 1D] with [00 00 00 00 00 00 00 00 0D].
Address Value Function
0x7F8E 0x00-0xFF X-offset add value, 0x00 / 0x01 / 0x02 for 0/+1/+2 pixel offset (Added to the default 2 offset)
Offsets of the images in the extracted file after using the tool:
- U1253A logo: Not there?
- Agilent screen: 0x1758A-0x17989
- Agilent screen: 0x1798B-0x17D8A (Same image, slightly shifted to the left).
Make a 128x64px image in Paint or whatever, save as monochrome BMP.
Use this converter: https://javl.github.io/image2cpp/ (https://javl.github.io/image2cpp/)
- Load the bmp.
- Tick "Flip image vertically".
- Draw mode: vertical - 1 bit per pixel.
- If the image color appears inverted, tick "Invert image colors".
- Click generate code.
- Download as binary.
- Open both the extracted firmware and .bin picture in HxD.
- In the image data, Right click over the data, click select All, Copy.
- Go to the FW data, Control+G, write this offset (hex):
- Agilent screen: 1758A
- 2nd Agilent screen: 1798B
- Right click on that byte, "Paste writing". If you get a warning like "This operation will change the file size", you're doing it wrong.
- Save the file.
-
This is great on 4.02 firmware!
On the other firmware versions, should we do another thread to attract prospective people who have problematic keysight/agilent DMMs with OLED displays?
I am just not sure that they will get to visit this thread since it is nested in microprocessor section..
-
- Download and install the firmware from Keysight: U1273AFirmwareUpdateSoftware-303.zip (https://www.keysight.com/us/en/lib/software-detail/instrument-firmware-software/firmware-update-for-u1273a-handheld-digital-multimeter-2371043.html).
If not available anymore, it's also attached (https://www.eevblog.com/forum/microcontrollers/8-bit-78k0-d78f0547-help-with-firmware-modification/?action=dlattach;attach=1983733).
Has to be 3.01:
The 3.01 uploader allows uploading of any firmware to the meter, it does not check the "current" version on the meter itself. The 3.03 uploader will check the current version on the meter, and if it is equal to or is newer then the firmware you are trying to upload, it will greet you with a message saying that your meter has the most current firmware and will not do the upload process.
Firmware uploader 3.01 only cares if two things are in place: firmware is there and is named "u1273ax_v301.ag" regardless of what actual version it is, and if the file is exactly 128KB.
-
Firmware uploader 3.01 only cares if two things are in place: firmware is there and is named "u1273ax_v301.ag" regardless of what actual version it is, and if the file is exactly 128KB.
Aha! Updated :-+.
But v3.01 file is named "U1273A_V301.AG", not "U1273AX_V301.AG"? Is this correct or did I download the wrong file?
I wonder if that updater could also update other similar DMMs (1253/1273 A/B) by just dropping any .AG file?
-
https://www.keysight.com/us/en/assets/ndx/9018-33296/miscellaneous/U1273AX-Firmware-Update-Software-Version-3-01.zip (https://www.keysight.com/us/en/assets/ndx/9018-33296/miscellaneous/U1273AX-Firmware-Update-Software-Version-3-01.zip)
Might be a different version downloaded:
In terms of loader being a universal one - that would be awesome, this project makes me want to have several kinds of these meters to test it with!
-
Everything finished after a titanic amount of work!
@onesystem could you test the binary to ensure it's still working?
For the sake of Google and forum search (And the crazy hours I spent digging and documenting everything up): Please edit the title to something like "Modded firmware for OLED replacement in Agilent/Keysight U1253A/B & U1273A(X)".
Absolutely no one is going to search "D78F0547" while trying to fix his display! :D.
Thanks!
-
Looks like I can change subject only for my part of the thread, you can copy subject and paste it in your replies and it should update it too!
-
Which firmware is safe to test on my meter do you think? Just the U1273A v303 and U1273AX v303?
I am not certain about the others - let me know if you are pretty sure it will not brick the meter to load v402 on it and also maybe the 1253 versions
I am about to load 303 1273A and 1273AX to test that they are working
2024-01-19 13:20 UDPATE: Loaded modded firmware 1273A v303 into 1273AX meter and it is working great. Screen works beautifully.
2024-01-19 13:34 UPDATE2: Loaded modded firmware 1273AX v303 into 1273AX meter and it is working great as before. Screen works beautifully.
2024-01-19 13:42 UPDATE3: firmwarre from 1253 or 1123 meter is not compatible with 1273AX, it bricks it. I could not test screen alighnment on it. I only presume that reversely, do not try to load 1273 firmware onto 1253 or 1123 meters.
-
The bootloader is never updated, so if you load a firmware for a different bootloader certainly it won't work.
U1237A and AX have the same bootloader functions in the same places so it works, same for U1253A and B, but it's different between 1253 and 1273.
How is it set into update mode?
If it doesn't rely on the app itself, like powering it on with a button pressed, it might be unbrickable.
And it should be, the update procedure can always go wrong, batteries dying, sudden power loss, connection failure...
However I don't have this device and I can't test anything.
-
Yes my meter is dead at the moment. After loading firmware it turned off and did not turn back on. To load its proper firmware i have to power on the meter. So I need to work it out, hopefully I did not kill it completely! Maybe I need to flash the chip direcly with unreversed byted firmware (since it "unreverses it" while loading into meter). But I still have to work that out - i.e. what equipment to buy for that and how to load it onto the chip.
-
What did you do to? How did you manage to brick it?
Even if the screen doesn't come out, it might be going into failsafe / update mode - try connecting it to the computer and running the updater!
In the worst case, yes, the reversed firmware should restore it.
Here's something: https://github.com/mnh-jansson/78k0-flash-utility/
-
Do you think I can accomplish it with this?:
https://www.ebay.com/itm/151229761950?chn=ps&norover=1&mkrid=711-117182-37290-0&mkscid=101&itemid=151229761950&targetid=1493511181865&device=c&mktype=pla&googleloc=9014964&poi=&campaignid=19851828444&mkgroupid=145880009014&rlsatarget=pla-1493511181865&abcId=9307249&merchantid=8561194 (https://www.ebay.com/itm/151229761950?chn=ps&norover=1&mkrid=711-117182-37290-0&mkscid=101&itemid=151229761950&targetid=1493511181865&device=c&mktype=pla&googleloc=9014964&poi=&campaignid=19851828444&mkgroupid=145880009014&rlsatarget=pla-1493511181865&abcId=9307249&merchantid=8561194)
I have never done work with MCUs birectly before, this is going to be my first time!
-
And here is another page with what seems to be some good information.
Can I use it?:
http://elm-chan.org/works/sp78k/report_e.html (http://elm-chan.org/works/sp78k/report_e.html)
-
You're not answering any of my questions!
I can't help unless you said what you did. Did you force-loaded the 1253A/B firmware into the 1273AX?
Must be 78K0, AFAIK 78K0S is completely different.
I was checking the bootloader to see if there was any failsafe mode.
This is what it does:
sub_060e: ; From reset vector and basic init
di ;060e 7b 1e
push hl ;0610 b7
mov a,#0x00 ;0611 a1 00
mov !mem_e2a7,a ;0613 9e a7 e2
mov BANK,#0x05 ;0616 13 f3 05 ; Set flash bank 5
movw ax,!0xbffc ;0619 02 fc bf ; Get data at flash address 0x1FFFC
cmpw ax,#0xfafa ;061c ea fa fa ; If not 0xFAFA
bnz lab_062c ;061f bd 0b ; Enter updade mode
mov BANK,#0x00 ;0621 13 f3 00
call !sub_040c ;0624 9a 0c 04
call !sub_7f00 ;0627 9a 00 7f ; Otherwise continue booting (Call app)
br lab_063d ;062a fa 11 ; Return from app, enter updade mode
So there isn't any failsafe procedure in the bootloader itself!
Agilent wasn't very nice here, all the firmwares have 0xFAFA there, should have used different values/addresses or additional checks to prevent such stupid bricking.
Their thinking probably was "As the entire flash is erased before updating, if the last bytes are ok, the rest will be too".
-
Sorry!
What I did is using the regular firmware uploader v3.01, uploaded the file "U1253B_V304_1123a.AG" after renaming it to the "U1273AX_V301.AG". Loading progress went all the way to the end, and meter went dead during the reboot which loader automatically forces it to go through at the end of loading of the firmware.
I tried to take out batteries and then placing them back in, pressing various buttons at different lengths of time, turning the lever to various positions. All while loader is connected via optical cable - no response from meter or the loader - it does not see the meter, meaning that one is not turning on and not communicating via it's optical interface.
-
* U1273 and 1253 are completely uncompatible, don't try cross-flashing! *
-
I know! It was totally my fault - I had a wild idea that all I will test is screen formatting and then I will load proper firmware back. I learned the hard way! Now I will have to load the right firmware using some kind of progammer which I still have to find and then connect to that chip hopefully without needing to remove it from board.
-
I think there's still some hope! We only need to mess those 0xFAFA bytes to force it into update mode.
As I posted earlier, this tool should be able to do it:
https://github.com/mnh-jansson/78k0-flash-utility/ (https://github.com/mnh-jansson/78k0-flash-utility/)
The serial connection is already there, you only need to follow the procedure stated in the programming manual to boot into flash mode:
- Power off.
- FLMD0 conected to VDD.
- Power on
- Wait at least ~5ms.
- Flash mode enabled.
Install python 3 (It's in the Microsoft store, or here (https://www.python.org/downloads/windows/)), then install pyserial by opening a command prompt and typing:
pip install pyserial
Download flash-util.py (https://github.com/mnh-jansson/78k0-flash-utility/blob/master/flash-util/flash-util.py).
Flash blocks are arranged in 1KB sectors, so last sector is 127, this is the one to erase. (Adjust COM port as required)
python flash-util.py -e -b 127 -p COM3
I sniffed the serial port output, this is what it sent, so it seems to work properly!
00 00 <-- ?? I guess to flush any data? Not specified in the prog. manual?
01 01 00 FF 03 <-- Reset
01 07 22 01 FC 00 01 FF FF DB 03 <-- Erase block from 0x01FC00 to 0x01FFFF
If everything goes well, this will force the bootloader into update mode!
-
Okay!
I am not sure how to get this meter to respond at all though - to do any adjustments on that chip I have to communicate to it somehow...
I found this application note from Renesas about building a programmer for this chip:
https://www.renesas.com/us/en/document/apn/78k0kx2-flash-memory-programming-programmer (https://www.renesas.com/us/en/document/apn/78k0kx2-flash-memory-programming-programmer)
Worst case scenario I can always build my own programmer for it.
-
Powershell output:
===================================================
PS C:\gits\78k0-flash-utility\flash-util> python flash-util.py -e -b 127 -p COM4
specified block: 127
setting port to: COM4
NEC Programmer v1.0
written by Martin Jansson
Requesting serial port and resetting chip...
Response: Processing in progress (BUSY)
Erasing block 127 ...
Sending erase block command..
Response: Processing in progress (BUSY)
error: Did not receive ACK, returning...
===================================================
So I must be doing someething wrong...
How exactly do I accomplish this?:
"
The serial connection is already there, you only need to follow the procedure stated in the programming manual to boot into flash mode:
- Power off.
- RST=GND, FLMD0=GND.
- Power on, wait at least 1ms.
- FLMD0=VDD, wait at least 2ms.
- RST=VDD
- Flash mode enabled.
All I did is toggle meter handle from off to on position and that was all. Maybe I need to do something on the circuit board itself?
-
Interesting!
When meter is off the output of powershell is different! So there is some kind of communication happening...
===============================================
PS C:\gits\78k0-flash-utility\flash-util> python flash-util.py -e -b 127 -p COM4
specified block: 127
setting port to: COM4
NEC Programmer v1.0
written by Martin Jansson
Requesting serial port and resetting chip...
error: Length less than 2
Erasing block 127 ...
Sending erase block command..
error: Length less than 2
error: Did not receive ACK, returning...
===============================================
-
You almost said "I did nothing of that, but it's not working, did I made something wrong?" :-DD.
Well, everything, you're not putting the mcu into flash mode so how is it going to work?
meaning that one is not turning on and not communicating via it's optical interface.
Ah, forgot about the isolation, then it might not work at all?
Maybe 9600bps is too fast for the optical interface, or the mcu has to enable it?
You might need to directly interface the RX/TX pins in the mcu.
But for sure it won't magically work by simply powering it on, the flash mode enabling procedure must be followed.
-
Ok. I will solder in wires to the legs of the chip, put meter back together and perform the booting into flash mode sequence. The way this meter is built, I cannot power it on with case opened.
I will post pics of the process in case anyone finds it useful.
And in terms of optical comm - if it will not work with that, I will use direct comm with the chip.
-
Check JP2, seems like a programming header? Is it connected to pins 10 (RST), 13 (FLMD0), 50 (RxD6) and 51 (TxD6) ?
-
JP2 pinout:
(top to bottom)
1. pin 50 P14/RxD6
2. pin 51 P13/TxD6
3. pins 18 EVSS,
60 AVSS
4. pins 16 REGC,
19 VDD,
20 EVDD
5. pin 10 RESET (via 1K resistor)
6. pin 13 FLMD0
Can these be used or should I solder?
-
Ah! There's a second UART in 50 (TxD6) and 51(RxD6).
In fact, that's the one used, check the manual (https://drive.proton.me/urls/SF51ZB1RF4#R0M7AdtgC0SV) pages 732 and 733.
The mcu reads any incoming pulses in FLMD0 after entering flash mode to set the comunication mode, 0 pulses sets UART6.
So you have easy access after all :).
1. RX (To cable TX)
2. TX (To cable RX)
3. GND
4. VDD
5. RESET
6. FLMD0
-
So to make sure I do it right:
1. Connect Rx and TX to PC using a USB to UART
2. Make sure meter is off, then short RESET and FLMD0 to ground for a moment, disconnect, then
2. Turn on meter
3. Short FLMD0 to VDD, then disconnect
4. Connect RESET to VDD, keep connected
5. Run the 78k0-flash-utility
-
Measure reset and FLMD0 voltages after powering the meter.
Likely, reset=VDD and fldm0=gnd.
1. Connect Rx and TX to the adapter, but don't connect it to the PC yet (Might cause voltage going to the mcu, powering it up).
2. Make sure meter is off. Short FLMD0 to VDD, better through a 100R-1K resistor (Just in case).
3. Turn on meter. Optional: Connect RESET to gnd for a fraction of a second to force a reset, leave unconnected. Shouldn't be necessary as the mcu has just been powered up.
4. Connect to PC.
5. Run the 78k0-flash-utility
-
Back alive!!!!
Once I erased the block, screen started showid "D...." without an hour glass when I turned meter back on again. It took several tries with uploader - kept telling me meter has to be powered off and on again, and then finally it started loading firmware. Meter is now working without problems again!
Thank you DavidAlfa!!!
-
Great job! Now we have the proof that the meter is unbrickable! :-+
I guess we could make a fail-safe mode too!
If there's any bug in the modded firmware crashing the firmware, read a button at power-on before the main app starts executing, and start the update mode.
But for that, button mapping must be done!
Which buttons are directly connected to the mcu?
What is their idle and switched levels?
-
Nice. Perhaps someone could attach the 78k0-flash-utility here, to ensure future availability?
-
IMHO relying in the forum storage is the least reliable way, but attached (https://www.eevblog.com/forum/microcontrollers/8-bit-78k0-d78f0547-help-with-firmware-modification/msg5287942/#msg5287942) anyways :D.
-
Great job! Now we have the proof that the meter is unbrickable! :-+
I guess we could make a fail-safe mode too!
If there's any bug in the modded firmware crashing the firmware, read a button at power-on before the main app starts executing, and start the update mode.
But for that, button mapping must be done!
Which buttons are directly connected to the mcu?
What is their idle and switched levels?
Pin 30 button [Dual/Exit] and [Setup] and all of the buttons to the right of them
Pin 31 all of the buttons to the left of [Dual/Exit] and [Setup] not including the [Dual/Exit] and [Setup]
Pin 34 (connected via Diode), buttons [Null/Scale] and [brightness/Setup]
Pin 35 (connected via Diode), buttons [MaxMin/Peak] and [Hz % ms/Log]
Pin 36 (connected via Diode), buttons [Trig/Auto Hold] and [Range/Auto]
Pin 37 (connected via Diode), buttons [Dual/Exit] and [Esc Shift/View]
Switched/unswitched levels are difficult to measure without soldering wires to the thing..
-
Unfortunately the modded flash appears to have bricked my U1253A. I haven't upgraded the display yet so I don't know if anything is being on the displayed but...
Before flashing the meter beeped when powered On and the update software reported "Link".
After flashing the meter no longer beeps when powered On and the updated software can no longer find the meter, reporting "No Link".
The update ran to completion with no problems reported during flashing so I don't suspect any issues with the flashing procedure.
The meter was running 1.20 of the official firmware before attempting to flash with the modded firmware.
I briefly read that there is a method to "unbrick" a meter I need to go back and read the details of that procedure I may give it a try I just wanted to report that at least for the U1253A there might be some issues.
Please let me know if there is any more information I can provide to help the creators troubleshoot the potential problem.
-
Thanks for your feedback and sorry for the trouble caused, will check what could have gone wrong.
Edit:
Crap! I made a stupid mistake...
I missed adjusting a jump address in the oled init sequence, had the U1273AX value (It's different in U1253A/B) so it'll be jumping to go-figure-where and crashing... :palm:.
FIXED
De-bricking should be pretty easy following the previous posts, please try the updated version!
I've triple-checked everything, everything seems fine now.
Compared to U1273A, the button layout seems different in U1253A, please trace the [Dual/Exit] button in the board so I can make a failsafe mode!
-
Wow. Thank you for such a quick fix.
I'll be tearing into the meter tomorrow to try to recover and re-flash and at the same time I'll trace out the button.
Thanks again!!
-
The app initialization sets P7-4 as inputs and P3-0 as outputs, so I'll assume P7.7 (pin 30) is reading the button.
This should work. If wrong, in the worst case it'll ignore the button, or always enter update mode.
The mod ended up cycling through the booting. Pressing the button does enter the boot mode which is so good, no need to direct connect again
-
Sorry didn't get it (What's the reason of showing the DMM off?), do your mean it's working as expected?
Power-on behaves normally?
Turning power on while holding Exit button sets Update mode?
-
Sorry this file is a .gif file, regular videos I cannot upload here. So if you download it and open it - it will be animated and will show you the result
-
Ah! You can't upload gifs here, the forum breaks them, won't work even after downloading it.
Try https://gifyu.com/ .
-
Oh okay!
https://gifyu.com/image/S05TS
-
Reduced timing unfortunately produced the same result. Meter is cycling through until button is pressed to get into programming mode
-
Hmmm ok, then it's other problem.
Maybe that flash area is not actually empty and I'm breaking something, will try placing the code elsewhere.
-
>>> Updated 1/24/2024 In the first post Reset and FLDM0 were wrong, the pins are now correctly assigned. :palm: <<<
Quick update on for the U1253A.
The Dual/Exit button (SW1) goes to Pin 33 P74/KR4.
The "Common" for the switch is shared with SW1-SW4 goes to Pin 34 P73/KR3.
Also for anyone that needs it here is the pinout of the programming header.
Pin1 -> FLDM0 (Pin 13)
Pin2 -> Reset (Pin 10)
Pin3 -> AVRef (Pin 59
Pin4 -> GND
Pin5 -> P13/TXD6 (Pin 51)
Pin6 -> P14/RXD6 (Pin 50)
I'll attempt to reprogram tomorrow.
Quick question?
Is the recovery process the same for the U1253A (D78F0547)?
Should the same block (127) be erased with command "python flash-util.py -e -b 127 -p COMx"?
Sorry I'm a bit out of my area with the MCU stuff. :-//
Thanks!
-
Yes! :-+
And the other side of the button? In the 1273 they seem to be multiplexed with diodes, no idea here.
Another U1273AX failsafe test!
The jump test should do nothing, it's just adding a jump between bootloader, custom place ands back to app, no failsafe of any kind.
Edit: Deleted files to keep users safe, I don't want them to brick their DMMs!
-
Completely missed that. |O
The "common" side which is shared with SW1-SW4 goes to Pin 34 P73/KR3.
-
Yes! :-+
And the other side of the button? In the 1273 they seem to be multiplexed with diodes, no idea here.
Another U1273AX failsafe test!
The jump test should do nothing, it's just adding a jump between bootloader, custom place ands back to app, no failsafe of any kind.
Ok so this is the best failsafe version so far. Meter operates as expected when I turn it on. If I go to [Setup], I can do whatever adjustment I need to do, but then when I exit the setup mode by pressing the same button again, it goes to boot mode. To exit boot mode I just need to turn meter off and on again using the main selector lever.
-
Hmm? How possible? It should only go into update if you hold Exit and turn the meter on.
-
Hmm? How possible? It should only go into update if you hold Exit and turn the meter on.
Because this meter performs "reboot" as in off/on sequence autamatically every time user tries to exit Setup menu - to exit Setup menu user presses and holds Setup button.
If I press and hold Dual/Exit button while turning on the meter, nothing happens. If I press and hold Setup button while turning meter on then it enters the boot mode.
-
Understood!
But better we find a more suitable button, entering update mode every time you exit the setup screen will be very annoying!
Please try the attached tests. I'm now testing the other 3 pins (P7.6, 7.5, 7.4). Try to find which butttons trigger update mode now.
Edit: Deleted files to keep users safe, I don't want them to brick their DMMs!
-
Understood!
But better we find a more suitable button, entering update mode every time you exit the setup screen will be very annoying!
Please try the attached tests. I'm now testing the other 3 pins (P7.6, 7.5, 7.4). Try to find which butttons trigger update mode now.
Somehow this update is problematic. After loading first firmware meter goes into loading screen but it is not detected by uploader. Do you think if I delete the same block as before it will resurrect it? I loaded "U1273AX_V301_failsafe_p74.ag" and this problem started.
-
Yes, that will always work. So with p74 it's not booting normally?
Doesnt make sense, it's the exactly the same code as the previously working test, except it's just reading a different pin!
sub_7f00: ; From bootloader
br !llab_7fdb ;7f00 9b db 7f ; Go to failsafe check
lab_7fdb: ; Failsafe check
mov pm7,#0xf0 ;7fdb 13 27 f0 ; Set P7.7-4 as input, P7.3-0 as output
mov pu7,#0xf0 ;7fde 13 37 f0 ; Enable P7.7-4 pullups
mov p7,#0x00 ;7fe1 11 07 00 ; P7.3-0 outputs low
movw ax,#0x0100 ;7fe4 10 00 01 ; Much smaller delay
lab_7fe7:
subw ax,#0x0001 ;7fe7 da 01 00
bnz lab_7fe7 ;7fea bd fb
bt p7.4,lab_7ff0 ;7fec cc 07 01 ; If P7.4 reads 1, button is not pressed
ret ;7fef af ; Button pressed, return to bootloader (Enter update mode)
lab_7ff0: ; Button not pressed
mov p7,#0x0f ;7ff0 11 07 0f ; All outputs high (Same as the app init)
br !lab_3015 ;7ff3 9b 15 30 ; Jump to main app
-
So now resetting the ports before jumping:
sub_7f00: ; From bootloader
br !llab_7fdb ;7f00 9b db 7f ; Go to failsafe check
lab_7fdb: ; Failsafe check
mov pm7,#0xf0 ;7fdb 13 27 f0 ; Set P7.7-4 as input, P7.3-0 as output
mov pu7,#0xf0 ;7fde 13 37 f0 ; Enable P7.7-4 pullups
mov p7,#0x00 ;7fe1 11 07 00 ; P7.3-0 outputs low
movw ax,#0x0100 ;7fe4 10 00 01 ; Much smaller delay
lab_7fe7:
subw ax,#0x0001 ;7fe7 da 01 00
bnz lab_7fe7 ;7fea bd fb
mov a,p7 ;7fec f0 07 ; Move P7 value into A
mov pm7,#0xff ;7fee 13 27 ff ; Clear port config
mov pu7,#0x00 ;7ff1 13 37 00
bt a.7,lab_7ff8 ;7ff4 31 7e 01 ; test A, bit 7
ret ;7ff7 af ; Return (Button pressed)
lab_7ff8:
br !lab_3015 ;7ff8 9b 15 30 ; Enter app (Not pressed)
Edit: Deleted files to keep users safe, I don't want them to brick their DMMs!
-
Agilent / Keysight U1273A / U1273AX
- If your device has firmware version v4.xx, it will work straight away, no firmware modification is required!
So why would you not just update your U1273A or U1273AX to Keysight V4.xx firmware?
Does that firmware only run on newer DMMs due to hardware changes?
-
Because you can't. The important functions are in the bootloader and it's never updated.
-
Ah, OK. So newer meters come with a newer bootloader (and associated functions). Whereas older meters are stuck with the bootloader they have and the outdated display drivers stored with the bootloader.
-
Yes. Theorically you could attach the programmer and load the entire v4 fw.
-
Yes. Theorically you could attach the programmer and load the entire v4 fw.
Since with regular firmware udpdates meter calibration is unaffected I only can presume that flashing firmware with programmer would affect the calibration parameters unless you copy them from that meter's firmware - something to keep in mind.
-
It's probably in the external EEPROM.
-
So now resetting the ports before jumping:
sub_7f00: ; From bootloader
br !llab_7fdb ;7f00 9b db 7f ; Go to failsafe check
lab_7fdb: ; Failsafe check
mov pm7,#0xf0 ;7fdb 13 27 f0 ; Set P7.7-4 as input, P7.3-0 as output
mov pu7,#0xf0 ;7fde 13 37 f0 ; Enable P7.7-4 pullups
mov p7,#0x00 ;7fe1 11 07 00 ; P7.3-0 outputs low
movw ax,#0x0100 ;7fe4 10 00 01 ; Much smaller delay
lab_7fe7:
subw ax,#0x0001 ;7fe7 da 01 00
bnz lab_7fe7 ;7fea bd fb
mov a,p7 ;7fec f0 07 ; Move P7 value into A
mov pm7,#0xff ;7fee 13 27 ff ; Clear port config
mov pu7,#0x00 ;7ff1 13 37 00
bt a.7,lab_7ff8 ;7ff4 31 7e 01 ; test A, bit 7
ret ;7ff7 af ; Return (Button pressed)
lab_7ff8:
br !lab_3015 ;7ff8 9b 15 30 ; Enter app (Not pressed)
Finally loaded the "U1273AX_V301_failsafe_p74.ag" on meter. Meter works fine, no problems at all.
I used DSD Tech SH-U06A to load it this time so I don't have to take apart optical comm and solder in the Rx Tx Gnd pins. See attached photos.
Now, what is the expected operation of this failsafe version?
-
It's just reading a different input. Try finding which button causes it to go into update mode (Holding while powering on).
Might not be connected to any button, that's why I made the four p77...p74 tests.
-
Wanted to give a BIG THANK YOU! to both you guys.
I replaced the display on my U1253A and upgraded the firmware today.
Attached pictures tell the story.
I also posted this success story in the testgear thread.
https://www.eevblog.com/forum/testgear/replacing-oled-screen-on-an-agilent-u1253a-multimeter/msg5311756/#msg5311756 (https://www.eevblog.com/forum/testgear/replacing-oled-screen-on-an-agilent-u1253a-multimeter/msg5311756/#msg5311756)
-
Forked k0dasm with the command.py and symbols.py changes to support the D78F0547 at https://github.com/bson/k0dasm
-
So there is NEC uPD78F0547 inside. My Fluke 189 uses Sharp SM6004 chip. No docs, no tools, etc. What was the reason for widely using a Japanese MCUs in the DMMs of the US brands? If there was a shortage of the domestic MCU designs back at that time?
-
IMHO relying in the forum storage is the least reliable way, but attached (https://www.eevblog.com/forum/microcontrollers/8-bit-78k0-d78f0547-help-with-firmware-modification/msg5287942/#msg5287942) anyways :D.
Just for reference, I also forked it at https://github.com/bson/78k0-flash-utility (https://github.com/bson/78k0-flash-utility)
-
So there is NEC uPD78F0547 inside. My Fluke 189 uses Sharp SM6004 chip. No docs, no tools, etc. What was the reason for widely using a Japanese MCUs in the DMMs of the US brands? If there was a shortage of the domestic MCU designs back at that time?
Maybe those design teams are in Asia, and they naturally gravitate to home-grown mcu's.
US based design teams are perhaps more focussed on bench / high-end gear, where "western" mcu's are common.
Just guessing. Maybe just cost driven.
-
So there is NEC uPD78F0547 inside. My Fluke 189 uses Sharp SM6004 chip. No docs, no tools, etc. What was the reason for widely using a Japanese MCUs in the DMMs of the US brands? If there was a shortage of the domestic MCU designs back at that time?
Maybe those design teams are in Asia, and they naturally gravitate to home-grown mcu's.
US based design teams are perhaps more focussed on bench / high-end gear, where "western" mcu's are common.
Just guessing. Maybe just cost driven.
I don't know about Fluke. Keysight's handheld multimeters are designed and produced by Escort Instruments, a Taiwanese company acquired by Agilent in 2008.
-
How to replace the Agilent / Keysight OLED display for just $10!
- Buy the display: Aliexpress (https://www.aliexpress.com/item/1005005701373912.html) (Or search for "SSD1309 8080").
(Attachment Link)
- You might need to install the Prolific drivers. If getting code 10, install the attached drivers.
- Make sure Windows is using them: Open the Device Manager, check those under USB devices/USB serial port and COM ports/USB serial port, replace driver if needed.
- Don't attempt loading a firmware from another model, it'll brick the device! (Not irreversible, see Recovering section below)
Agilent / Keysight U1273A / U1273AX
If your device has firmware version v4.xx it will work straight away, no firmware modification is required!
- Confirmed working!
- Download and extract U1273A(X)_V303_mod.zip.
- Run the updater.
- Original installers from Keysight: U1273A (https://www.keysight.com/zz/en/lib/software-detail/instrument-firmware-software/firmware-update-for-u1273a-handheld-digital-multimeter-2371043.html), U1273AX (https://www.keysight.com/zz/en/lib/software-detail/instrument-firmware-software/firmware-update-for-u1273ax-handheld-digital-multimeter-2683029.html) .
Must be v3.01, newer version will check the current firmware and block the update if already in the latest version!
Just change the firmware name to U1273A(X)_V301.AG. (A or AX).
Agilent / Keysight U1253A
- Confirmed working!
- Download and unpack Agilent U1253A Firmware Update V120_mod.zip.
- Run the updater.
Agilent / Keysight U1253B
- Same mod as 1253A, so it should work.
- Download and extract U1253B_V304_1123a_mod.zip.
- Run the updater.
Reverse enginnering details
All the bits & low-level details can be found few posts below (https://www.eevblog.com/forum/microcontrollers/8-bit-78k0-d78f0547-help-with-firmware-modification/msg5284399/#msg5284399).
Recovery
If something goes wrong, it's pretty easy to recover using a usb-serial converter, read the messages starting here (https://www.eevblog.com/forum/microcontrollers/8-bit-78k0-d78f0547-help-with-firmware-modification/msg5287942/#msg5287942).
Great thanks to you guys working on thist project！my meter is now back to live again.
But as a reminder, I think you guys should uploader your work on github or a similar platform and attach a License to it.
I am from China and have already seen someone selling this firmware on the local network. :palm: :palm: :palm:
-
THANKS A LOT!!!!!!!! :clap: :clap: :clap: :clap: :clap: :clap: :clap: :clap: :clap:
I need to update a 1253A, can anyone make a DIY optic cable or connect directly RXTX from and USBtoSerie standard interface to the meter to use with the updater in the second post? I lost in somewhere my interface cable and prefer not to buy a new one if it is possible.
THANKS AGAIN, GREAT PERFECT A PROFESSIONAL JOB!
-
You can make an optic cable for sure, it is actually quite simple circuitry. Do you by chance have a 3D printer? that would be needed to print out a snap-in head that would align the LEDs of the UART with meter LEDs. I can throw together a printable file and a circuit board quickly if you are interested.
If it is a bit too involved, then what can be done is to use regular FTDI UART usb cable/dongle and connect directly to the meter internal header (which is definitely present in U1273AX on the top right of the board. Not sure where it is in 1253A
-
No, the internal header is a different port, I don't think it's "talkative"?
-
In U1273AX port is fully talkative, I did couple of firmware updates from it directly instead of using the optical UART. It was the same port that I used to "unbrick" the meter (with your smart guidance!) when I messed it up, remember?
-
Are you sure?
I recall you stripped the original cable to unbrick the DMM, accessing rx/tx signals and connecting them to the header.
But that's the only use for it that I remember, the updating was done with the optical cable, right?
Or did you update through the header here (https://www.eevblog.com/forum/microcontrollers/8-bit-78k0-d78f0547-help-with-firmware-modification/msg5289082/#msg5289082)?
-
I am definitely sure. Later on I even posted that I got a FDTI USB to UART from Amazon which I connected directly and was able to use that connection for uploading of firmware using the stock Keysight/Agilent firmware uploader. It definitely detected the meter and cycled through the update process without problems.
-
Or did you update through the header here (https://www.eevblog.com/forum/microcontrollers/8-bit-78k0-d78f0547-help-with-firmware-modification/msg5289082/#msg5289082)?
Yep, I used it there too.
-
Thanks Again! I did try today to buy in my country the OLED display and none it's compatible, I need to buy in ebay or in aliexpress then would took one month to arrive.
I can make the IR-USB cable meanwhile , I have several CNC machibes to make the head, I can post results here.
Anybody used another colour than Yellow for the display? It's less readable in white than yellow?
Thanks again for your enormous work, it's a real shame that Keysight not provided this firmware mod.
-
I personally liked the original yellow color of OLED, also I think DavidAlfa mentioned something about yellow OLEDs having the most time longevity but I might be mistaken on that.
-
Originally the blue compound on oleds had the lowest livespan * by a lot *.
Not sure nowadays, but probably still the weakest.
-
I found my U1173B and did a teardown and RE for it. The circuit diagram was not carefully checked and organized so it looks a bit messy, but it should be readable.
-
Thanks Gamalot, with the pictures I can make an own cable. Somebody try the update with the bluetooth version? Thanks
-
Thanks for your work in this thread DavidAlfa and onesystem!
I bought a Agilent U1273Ax on eBay with condition listed as not working.
When I got it home the buzzer made no noise and the screen was dead but it pulled 18mA from my bench supply.
After some fiddling I managed to reset it to default settings and was greeted by its silly startup sound: it made me happy to know it works :)
So I ordered a display on TME, I choose white color because they had it in stock so it was delivered in just two days.
And now I have a working meter :)
So this is another tested OLED display source if anyone is looking and don't want to buy off Aliexpress or eBay :)
White: https://www.tme.eu/en/details/rex012864hwpp3n0/graphical-oled-displays/raystar-optronics/rex012864hwpp3n00000/ (https://www.tme.eu/en/details/rex012864hwpp3n0/graphical-oled-displays/raystar-optronics/rex012864hwpp3n00000/)
Yellow: https://www.tme.eu/en/details/rex012864hypp3n0/graphical-oled-displays/raystar-optronics/rex012864hypp3n00000/ (https://www.tme.eu/en/details/rex012864hypp3n0/graphical-oled-displays/raystar-optronics/rex012864hypp3n00000/)
-
Per, how do you connect to the multimeter to update the firmware? Is that serial port in the top left corner equivalent to the optical port? Thanks
-
Hi, that's the internal debug port, I was meaning to buy the Keysight U1173B optical cable from TME but when I login as a private person it's no longer possible to buy it and I couldn't be bothered to do it from my company: their loss...
I have had this Sparkfun TTL adapter (https://www.sparkfun.com/products/449) since forever, it is very convenient: in this case I power it from the multimeters own VCC, this creates the proper level shift voltage (black and red cables in the picture).
Then TX/RX is the yellow cables, I was meaning to close the meter back up (hence used long cables) but in the end I used a bench supply directly on the multimeters battery contacts to power it during the update...
The update tool that is linked on page-1 seems to have no problems to work with the USB to serial adapter I used (FTDI chipset) I guess it works with any serial device in Windows...
-
Thanks Hansson, I think that it's not possible to use debugging port to update firmware. Thanks
-
Start reading few post back (https://www.eevblog.com/forum/microcontrollers/8-bit-78k0-d78f0547-help-with-firmware-modification/msg5464819/#msg5464819).
-
Thanks a lot, we just saved 2x U1253B !
I buy "midas" oled:
https://midasdisplays.com/shop/oled/oled-graphic/mcot128064ey-ym/
Works great.
Unfortunately the capacitive measurement does not work anymore with the new firmware U1253B !???
(Both MM affected)
-
Does it work again with unmodified fw?
Maybe the patch area was not empty after all, I could try relocating the code elsewhere.
-
I'm having trouble upgrading the firmware version of my U1253B (from 2.26 to 3.04). The screen keeps showing "D...." and the PC keeps repeatedly asking me to cycle the power of the multimeter to continue the upgrade process. I gave up after trying this dozens of times. Any suggestions? |O
-
Try official update first?
-
Try official update first?
It was the official one. :(
I actually tried every version I could get my hands on, the official 2.26 and 3.04, as well as the patched 3.04.
-
Can't tell. Maybe bad cable driver? Depleted batteries?
-
Can't tell. Maybe bad cable driver? Depleted batteries?
I've tried the original U1173B and my DIY CH340 cable, but none of them worked.
Regarding the battery, I tried powering it with a bench power supply.
I also used the method you mentioned in post #33, but there was no visible change.
-
Can't help, sorry.
-
Can't help, sorry.
Thank you very much for your reply. Now the only hope left is whether it is possible to write the firmware directly through the Flash Utility.
-
The screen keeps showing "D...." and the PC keeps repeatedly asking me to cycle the power of the multimeter to continue the upgrade process. I gave up after trying this dozens of times. Any suggestions? |O
Are you sure the U1173B optical cable is working?
Try disabligng any other COM ports in the Device manager.
Also try changing the assigned port to COM2 or COM3, removing the cable and plugging it back afterwards.
Just to make sure, try with a USB 2.0 socket!
I also used the method you mentioned in post #33, but there was no visible change.
This (https://www.eevblog.com/forum/microcontrollers/8-bit-78k0-d78f0547-help-with-firmware-modification/msg5287942/#msg5287942) is only to start the mcu into native bootloader mode.
It's totally unrelated to the Keysight bootloader the updater talks to.
Now the only hope left is whether it is possible to write the firmware directly through the Flash Utility.
Theorically yes, you could. But it's risky!
First, I would try only erasing block 127, then writing a ramdom 1KByte file to it.
If it fails, the bootloader will be still intact and enter update mode automatically.
python flash-util.py -e -b 127 -p COM3
python flash-util.py -f "1kb_file" -b 127 -p COM3
If it was able to erase and write that block, then you can try wiping the chip and writing the whole firmware.
You need to first convert the original file into the native binary with tool_U1253B_U1273A (Available here (https://www.eevblog.com/forum/microcontrollers/8-bit-78k0-d78f0547-help-with-firmware-modification/msg5284399/#msg5284399)):
tool.exe firmware.AG firmware.bin
Then flash it:
python flash-util.py -e -p COM3
python flash-util.py -f firmware.bin -p COM3
-
Thank you very much for such a detailed reply, I have double checked the cables and as mentioned I have also tried different cables and changed port numbers. I even found an old Thinkpad T410 laptop with only USB 2.0 and installed WIndows 7/8.1/10 operating system, etc., without success. That's why I said my last hope is to use Flash Tools to write the firmware, I'll try it soon and report back.
-
Pinout of ports on U1253B.
-
My CH340 based U1173B clone.
-
How does that clone compare to the official cable?
It seems nowhere close to me, looks like the original cable goes inside of the socket while yours is flat.
(https://ce8dc832c.cloudimg.io/v7/_cdn_/84/A8/30/00/0/232008_1.jpg?width=640&height=480&wat=1&wat_url=_tme-wrk_/tme_new.png&wat_scale=100p&ci_sign=ac914ef99eb2cd9858d6b562de0e0587e8d3554d)
Pinout of ports on U1253B.
Just trace the same pins:
1. pin 50 P14/RxD6
2. pin 51 P13/TxD6
3. pins 18 EVSS,
60 AVSS
4. pins 16 REGC,
19 VDD,
20 EVDD
5. pin 10 RESET (via 1K resistor)
6. pin 13 FLMD0
-
It works just as well as the original, maybe a little better, since the PL2303 converter that Keysight used in their cables is no longer supported by Windows 11.
One thing I thought of before trying to use the flash tool directly was to wire out the reset signal to a button, as I found that my U1253B didn't always have a reliable power-on reset.
-
When debugging my U1273AX after flashing wrong firmware onto it I did a reset of the chip by simply shorting two wires for a moment and that worked for me.
-
Thanks to everyone, I was able to change the screen, update with the modified firmware and revive a U1253A without any problems (using the Bluetooth adapter). EVERYTHING WAS PERFECT, THANKS TO THOSE WHO MADE THIS POSSIBLE.
Gracias DavidAlpha por tu esfuerzo!
-
This is an off-topic reply but I'm hoping it helps save someone else:
I have been meaning to put NiMh batteries in the U1273Ax I showed on the previous page but have not been to IKEA yet.
I thought for sure it can work fine with some Alkalines for just a few weeks.
They where unused and from the same batch, expiry date December 2027
Looks like the second cell from the left in the attached picture shorted.
It smells burnt and is blackened, however all cells show quite nominal voltages from left to right both with a high and low impedance measurement:
1.497v 1.461v 1.485v 1.524v (I did check the batteries voltage before putting them in the meter and then they where all within a few mV).
So I expected something inside the meter had shorted (like a capacitor) but nothing looked burnt.
So I powered up the meter from a bench PSU and it draws a normal load and works fine.
So this is your call to find all Alkalines batteries in your possession and get rid of them, thank me later :)
In my case the only part that took damage was one of the battery series metal clips, so I got lucky.
I was going to measure something with the meter and it was totally dead: I guess the clip no longer made contact and that stopped the carnage...
-
They look cheap, don't put crappy batteries in expensive equipment, use the good stuff like Energizer, Duracell...
-
They look cheap, don't put crappy batteries in expensive equipment, use the good stuff like Energizer, Duracell...
Thanks but I respectfully disagree: I have Energizer batteries that leaks when unused in the original plastic packaging.
My thinking for putting "cheap brand" (these are marked by a local store chain in Sweden) is that unlike the large names they probably don't spend time eeking out the last bit of battery capacity:
With the hope that there should be more internal spacing for the internal seals, obviously that didn't work in this case but my only advice for everyone in this thread is to not use Alkalines, ever.
The previous owner seem to have had a battery leak in this meter too, one of the battery posts is degraded just like in Daves video #1564.
-
Hi, I use the U1253A today to measure capacitors and the meter it's dead, change the scale up to mF and nothing happens. Any idea? Thanks
-
Define "dead".
Or is it only failing to scale to mf?
@onesystem could you test this on yours?
-
Sorry @DavidAlfa!, yes, the capacitor measurement reads nothing, change automatically from nF to uF and then to mF, after few seconds shows the overrange "OL" but never sees the capacitor. Before flash the new firmware I did measured a couple of caps (with inverted screen) and did works ok. I attach an image of the problem.
EDIT:Everything indicates that it will make a normal measurement going through all the scales but as if I never connected the capacitor to the measurement circuit. If I connect the thermocouple (same dial position but using the shift) the measurement is perfect.
-
@Tarloth
Is the capacitor in circuit, or out of circuit?
What is the expected capacitor value? Is it within the measurement range of your meter (see specs)?
-
Make sure this is a mod issue!
Flash original and try again, same cap, same conditions.
If working, then I'll have a look.
-
@Tarloth
Is the capacitor in circuit, or out of circuit?
What is the expected capacitor value? Is it within the measurement range of your meter (see specs)?
Hi voltsandjolts, as seen in the attached image, the capacitor is a small electrolytic of 10uF fixed to the multimeter test leads. The values it's aprox to the center of multimeter range.
-
Make sure this is a mod issue!
Flash original and try again, same cap, same conditions.
If working, then I'll have a look.
Hi David, attach the image, with the original firmware works ok, Thanks for your effort
-
@Tarloth
Is the capacitor in circuit, or out of circuit?
What is the expected capacitor value? Is it within the measurement range of your meter (see specs)?
Hi voltsandjolts, as seen in the attached image, the capacitor is a small electrolytic of 10uF fixed to the multimeter test leads. The values it's aprox to the center of multimeter range.
Ahh, ooops, I just looked at the thumbnail and didn't notice the capacitor, my bad.
-
No problem, most of the time I don't even see the pictures!
I suspect the bug is the same one that fbpicsous reported a while ago for the U1253B.
Anyway I am more than grateful for the work they took to produce this firmware, it's amazing!
-
Okey! I'll try to find what's breaking that, probably some pattern search & replace that went too far.
This will only be fixed if you're willing to perform plenty of tests flashing different firmwares, until the place causing the bug is found.
About that previous bug report, he never came back, I can fix nothing that way, lazy people should just buy the $100 display.
-
David, count on me for do as many tests as necessary, it is the least that I can do to honor the effort that you have made.
---------
David, cuenta conmigo para la cantidad de pruebas que sean necesarias, es lo mínimo que puedo hacer para honrar el esfuerzo que ustedes hicieron.
THANKS
-
I moved the routines elsewhere (To 0x7C00), made different tests replacing only certain calls.
Try in the same order as the filenames (1, 2, 3...).
The display won't look correct on most of them, ignore that, find the first one causing the capacitance bug.
################################
sub_7c00: <<--- NEW OLED INIT ROUTINE
call !sub_04f5 ;7c00 9a f5 04 <<--- Call original init
movw ax,#0x00a1 ;7c03 10 a1 00 <<--- Segment remap cmd (Y-mirror)
call !sub_05d1 ;7c06 9a d1 05 <<--- Send cmd
movw ax,#0x00c0 ;7c09 10 c0 00 <<--- Scan direction cmd (X-mirror)
call !sub_05d1 ;7c0c 9a d1 05 <<--- Send cmd
ret ;7c0f af <<--- Return
################################
sub_7c10: <<--- NEW OLED POSITION ROUTINE
push hl ;7c10 b7
push ax ;7c11 b1
movw ax,sp ;7c12 89 1c
movw hl,ax ;7c14 d6
mov a,[hl] ;7c15 87
xch a,x ;7c16 30
mov a,[hl+0x06] ;7c17 ae 06
movw hl,ax ;7c19 d6
mov a,#0xb0 ;7c1a a1 b0 <<--- Row cmd
or a,l ;7c1c 61 6e
mov x,#0x00 ;7c1e a0 00
xch a,x ;7c20 30
call !sub_05d1 ;7c21 9a d1 05 <<--- Send cmd
mov a,h ;7c24 67 <<--- Move column value to reg A
cmp a,!mem_7c2e ;7c25 48 2e 7c <<--- Compare with subtract value at 0x7c2e
bnc lab_7c2d ;7c28 9d 03 <<--- If carry set, load A with subtract value so it becomes 0 when subtracting
mov a,!mem_7eca ;7c2a 8e 2e 7c
lab_7c2d:
sub a,#0x02 ;7c2d 1d 02 <<--- Subtract 2 to column value.
mov h,a ;7c2f 77 <<--- Update H reg for later use in lower column cmd
and a,#0x0f ;7c30 5d 0f <<--- Isolate lower column data
mov x,#0x00 ;7c32 a0 00
xch a,x ;7c34 30
call !sub_05d1 ;7c35 9a d1 05 <<--- Send cmd
mov a,h ;7c38 67 <<--- Move column value to reg A
ror a,1 ;7c39 24 <<--- Rotate 4 bits to the left to get higher column bits
ror a,1 ;7c3a 24
ror a,1 ;7c3b 24
ror a,1 ;7c3c 24
and a,#0x0f ;7c3d 5d 0f <<--- Isolate higher column data
or a,#0x10 ;7c3f 6d 10 <<--- High column cmd
mov x,#0x00 ;7c41 a0 00
xch a,x ;7c43 30
call !sub_05d1 ;7c44 9a d1 05 <<--- Send cmd
pop ax ;7c47 b0
pop hl ;7c48 b6
ret ;7c49 af <<--- Done, return
################################
sub_7c4a: <<--- NEW OLED DRAW ROUTINE
push hl ;7c4a b7 <<--- Same as original function
push ax ;7c4b b1
push ax ;7c4c b1
movw ax,sp ;7c4d 89 1c
movw hl,ax ;7c4f d6
mov a,[hl+0x0a] ;7c50 ae 0a
inc a ;7c52 41
mov [hl+0x0a],a ;7c53 be 0a
mov x,#0x00 ;7c55 a0 00
xch a,x ;7c57 30
push ax ;7c58 b1
mov a,[hl+0x08] ;7c59 ae 08
mov x,#0x00 ;7c5b a0 00
xch a,x ;7c5d 30
call !sub_7c10 ;7c5e 9a 10 7c <<--- Call new oled position function
br !lab_0643 ;7c61 9b 43 06 <<--- Continue in original function
-
Starting the tests, I would like to point out that the files are identified by Windows Defender as a serious virus. I have ignored it but it may cause problems in the future.
-
No idea why (But not imposible, I could be infected), here's Virustotal report for the file downloaded from the forum:
https://www.virustotal.com/gui/file/fc30981c573c42b18c7cd09bb6a76236332ee36d935caecb8fefceb01b9ec226?nocache=1 (https://www.virustotal.com/gui/file/fc30981c573c42b18c7cd09bb6a76236332ee36d935caecb8fefceb01b9ec226?nocache=1)
-
The tests was completed, lamentably the multimeter it's a brick now, any suggestion to unblock it?
File 1: screen inverted, Capacitance ok
File 2: Screen ok, capacitance Ok
File 3: Garbage in screen, a musical scale it's played, multimeter not respond to any successive upgrade, everything fails.
Link to video shown the fail https://drive.google.com/file/d/1SJMNOnMH57Hq_H5YWvAYYFderRuczy_d/view?usp=sharing (https://drive.google.com/file/d/1SJMNOnMH57Hq_H5YWvAYYFderRuczy_d/view?usp=sharing)
-
Hi David, file 2,3 an 4 are reported in defender as Trojan:Win32/Wacatac.B!ml
-
Must be a false positive, the files are identical except the areas of the firmware.
Upload them to VirusTotal and see.
Sorry - made a stupid mistake :palm: Swapped the addresses of oled position and oled draw... so the DMM will crash.
I checked it four times before uploading to avoid something like this, but I was tired and didn't realize about my mistake.
Please run the unbricking procedure (https://www.eevblog.com/forum/microcontrollers/8-bit-78k0-d78f0547-help-with-firmware-modification/msg5287942/#msg5287942).
Attached the corrected files - Also for the U1253B.
These tests uses again 0x7F60 - only, leaving 0x7EE6 and 0x7EAC areas untouched.
Let's see if the capacitance keeps working! (I don't think so)
Edit: It's working now, files removed, updated main post.
-
Don't worry David, these things happen when you experiment, it's the price of doing new things!
I'm finishing some things and I'm already trying the unlocker, Thanks
-
DavidAlfa:
Is the JP2 you mentioned in the https://www.eevblog.com/forum/microcontrollers/8-bit-78k0-d78f0547-help-with-firmware-modification/msg5288164/#msg5288164 (http://message) the one named JP12 in top of the board in U1253? I edit this message because I located all the signals and pinout.
-
Maybe you already found it but the pinout is shown in this post for JP12:
https://www.eevblog.com/forum/microcontrollers/8-bit-78k0-d78f0547-help-with-firmware-modification/msg5293273/#msg5293273 (https://www.eevblog.com/forum/microcontrollers/8-bit-78k0-d78f0547-help-with-firmware-modification/msg5293273/#msg5293273)
-
Thanks Per Hansson, yes, I found it, connect pin FLDM0 to AVRef (+3V) GND to USB-USART GND and cross rx and tx between multimeter and USB-USART . Execute the command but obtain an error
(I have the USB-USART in com3 too)
PS ....Agilent> python flash-util.py -e -b 127 -p COM3
specified block: 127
setting port to: COM3
NEC Programmer v1.0
written by Martin Jansson
Requesting serial port and resetting chip...
error: Length less than 2
Erasing block 127 ...
Sending erase block command..
error: Length less than 2
error: Did not receive ACK, returning...
Any idea?
-
Something must be wrong.
Please re-read and make sure your usb-serial adapter is working by bridging RX and TX and typing something in the terminal.
The adapter should be TTL level, not RS232!
1. RX (To cable TX)
2. TX (To cable RX)
3. GND
4. VDD
5. RESET
6. FLMD0
Measure reset and FLMD0 voltages after powering the meter.
Likely, reset=VDD and fldm0=gnd.
1. Connect Rx and TX to the adapter, but don't connect it to the PC yet (Might cause voltage going to the mcu, powering it up).
2. Make sure meter is off. Short FLMD0 to VDD, better through a 100R-1K resistor (Just in case).
3. Turn on meter. Optional: Connect RESET to gnd for a fraction of a second to force a reset, leave unconnected. Shouldn't be necessary as the mcu has just been powered up.
4. Connect to PC.
5. Run the 78k0-flash-utility
-
Good news!
Flash-Util never workd BUT I try to use the updater (the exe program) and after several on-off detects the multimeter and update to the original firmware, using the same usb-serie adapter and cables that fail with the flash-util utility.
Yes, the usb-serie it's TTL level and I use it frequently to read usart in microcontroller boards and works ok. Something was wrong with the FLDM0 I think (I did double check 3 volt level).
After that I update to the last mod that you attach few messages ago using the BT adapter, update perfect, restart with the screen correct, but few minutes after begin to test the multimeter, the battery exhausts and self shut down.
It was abnormal because the battery was not depleted, but after a full charge I will test it again.
When I have any news I wrote again! THANKS
-
I did change the battery, I found a new one in my desk.
Everything seems perfect!!! I test Capacitance and the other functions and seems ok, BRAVO!!!!! :-+
I use the file in this message https://www.eevblog.com/forum/microcontrollers/8-bit-78k0-d78f0547-help-with-firmware-modification/msg5600941/#msg5600941 (https://www.eevblog.com/forum/microcontrollers/8-bit-78k0-d78f0547-help-with-firmware-modification/msg5600941/#msg5600941)
-
Great! I updated the files for U1253A/B in the main post.
-
Thanks again David!
-
Recent update fixed the capacitor function on my 1253A. :-+
Thank you David
-
I'm trying to unify the mod so it's almost the same for all, same code, same areas, except few specific bootloader addresses.
Someone with U1273A(X) - and able to unbrick something goes wrong - please try this!
- Display init: sub_7f60:
sub_7f60:
call !sub_0994 ;7f60 9a 94 09 <<<--- Call original function
movw ax,#0x00a1 ;7f63 10 a1 00 <<<--- Segment remap cmd (Y-mirror)
call !sub_05d1 ;7f66 9a d1 05 <<<--- Send cmd
movw ax,#0x00c0 ;7f69 10 c0 00 <<<--- Scan direction cmd (X-mirror)
call !sub_05d1 ;7f6c 9a d1 05 <<<--- Send cmd
ret ;7f6f af <<<--- Return
- Set position: sub_7f70:
sub_7f70:
push hl ;7f70 b7 <<<--- Same as original function
push ax ;7f71 b1
movw ax,sp ;7f72 89 1c
movw hl,ax ;7f74 d6
mov a,[hl] ;7f75 87
xch a,x ;7f76 30
mov a,[hl+0x06] ;7f77 ae 06
movw hl,ax ;7f79 d6
mov a,#0xb0 ;7f7a a1 b0 <<<--- Row cmd
or a,l ;7f7c 61 6e
mov x,#0x00 ;7f7e a0 00
xch a,x ;7f80 30
call !sub_05d1 ;7f81 9a 68 0A <<<--- Send cmd
mov a,h ;7f84 67 <<<--- Move column value to reg A
cmp a,!mem_7f8e ;7f85 48 8e 7f <<<--- Compare with subtract value at 0x7f8e
bnc lab_7f8d ;7f88 9d 03 <<<--- If carry set,
mov a,!mem_7f8e ;7f8a 8e 8e 7f <<<--- Load A with subtract value at 0x7f8e so it becomes 0 when subtracting
lab_7f8d:
sub a,#0x02 ;7f8d 1d 02 <<<--- Subtract 2 to column value
mov h,a ;7f8f 77 <<<--- Update H reg for later use in lower column cmd
and a,#0x0f ;7f90 5d 0f <<<--- Isolate lower column data
mov x,#0x00 ;7f92 a0 00
xch a,x ;7f94 30
call !sub_05d1 ;7f95 9a 68 0A <<<--- Send cmd
mov a,h ;7f98 67 <<<--- Move column value to reg A
ror a,1 ;7f99 24 <<<--- Rotate 4 bits to the left to get higher column bits
ror a,1 ;7f9a 24
ror a,1 ;7f9b 24
ror a,1 ;7f9c 24
and a,#0x0f ;7f9d 5d 0f <<<--- Isolate higher column data
or a,#0x10 ;7f9f 6d 10 <<<--- High column cmd
mov x,#0x00 ;7fa1 a0 00
xch a,x ;7fa3 30
call !sub_05d1 ;7fa4 9a 68 0A <<<--- Send cmd
pop ax ;7fa7 b0
pop hl ;7fa8 b6
ret ;7fa9 af <<<--- Done, return
- Drawing: sub_7faa:
sub_7faa:
push hl ;7faa b7 <<<--- Same as original function
push ax ;7fab b1
push ax ;7fac b1
movw ax,sp ;7fad 89 1c
movw hl,ax ;7faf d6
mov a,[hl+0x0a] ;7fb0 ae 0a
inc a ;7fb2 41
mov [hl+0x0a],a ;7fb3 be 0a
mov x,#0x00 ;7fb5 a0 00
xch a,x ;7fb7 30
push ax ;7fb8 b1
mov a,[hl+0x08] ;7fb9 ae 08
mov x,#0x00 ;7fbb a0 00
xch a,x ;7fbd 30
call !sub_7f70 ;7fbe 9a 70 7f <<<--- Call new oled position function
br !lab_0ad9 ;7fc1 9b d9 0a <<<--- Continue in original function
Hex bytes:
9A 94 09 10 A1 00 9A 68 0A 10 C0 00 9A 68 0A AF B7 B1 89 1C D6 87 30 AE 06 D6 A1 B0 61 6E A0 00 30 9A 68 0A 67 48 8E 7F 9D 03 8E 8E 7F 1D 02 77 5D 0F A0 00 30 9A 68 0A 67 24 24 24 24 5D 0F 6D 10 A0 00 30 9A 68 0A B0 B6 AF B7 B1 B1 89 1C D6 AE 0A 41 BE 0A A0 00 30 B1 AE 08 A0 00 30 9A 70 7F 9B D9 0A
Because the entire firmware can't be disassembled, a manual pattern search and replace was performed:
- INIT: "9A 94 09" (call !sub_0994) -> "9A 60 7F" (call !sub_7f60)
- POSITION: "9A 20 0B" (call !sub_0b20) -> "9A 70 7F" (call !sub_7f70)
- DRAW: "9A C2 0A" (call !sub_0ac2) -> "9A AA 7F" (call !sub_7faa)
Patching offsets: ( .AG file in updater format, not reversed)
Address Value Function
0x18095 0x0C / 0x8C X-mirror off / on
0x1809B 0x0A / 0x1A Y-mirror off / on
0x18071 0x00-0xFF X-offset subtract value, nibble-swapped, so 0x00 / 0x10 / 0x20 for 0/-1/-2 pixel offset (Subtracted to the default 2 offset)
If for whatever reason, instead subtracting you want to increase the column address, patch as following:
0x18072 Replace [D1 F7 E8 E8 30 D9 F7 E8 84] with [D0 00 00 00 00 00 00 00 00].
Address Value Function
0x18071 0x00-0xFF X-offset add value, nibble-swapped, so 0x00 / 0x10 / 0x20 for 0/+1/+2 pixel offset (Added to the default 2 offset)
-
I just tested this last firmware today (U1253B).
It works really well ! Capacitive measurement also !
Many, many thanks for all your work! :-+ :-+ :-DMM
-
Great! :-+
Did anyone try the latest test from above?
-
Hey Brains trust I have a U1461A Insulation Multimeter that uses a u1273-26501 Display that has got a case of the fade, Does anyone know or can look to see if the firmware mod can be done for this meter
-
The cheap oled might work out of the box, give it a try?
The fw size is 256KB, so it must be a different uC. Open it out and show some pictures!
Edit: It's a UPD78F1168A (12:30), uses 78K0R architecture (https://www.renesas.com/en/document/mas/78k0r-microcontrollers-users-manual-instructions), way different than 78K0 used by the MCUs on u1253/73 (16-bit mcu vs 8-bit).
https://www.youtube.com/watch?v=wpEXm8bFlX0&t=755 (https://www.youtube.com/watch?v=wpEXm8bFlX0&t=755)
-
I found a way to disassemble the firmware on 78Kxx devices!
Download "CubeSuite+ for CA,CX" from Renesas (https://www.renesas.com/en/document/swe/evaluation-software-cs-cacx-v40500-single-download) (Requires registration) or Drive (https://drive.google.com/file/d/1zqzHP9Db_V7f1a-1PThDxuJrSigpdqi3), then follow the attached picture.
Loading binaries doesn't work (Throws illegal file error), but Hex does, can be converted with HxD (Export... 32-bit Intel Hex).
The file from U1461A firmware update (U1461A_V302.AG) needs the same byte/nibble swapping as U1273, so use the same tool, then load the output into HxD and export as Hex.
Attached the files for anyone wanting to play with them.
I located the oled initialization at address 0x130
303132 MOVW AX,#3231H
33 XCHW AX,BC
343536 MOVW DE,#3635H
37 XCHW AX,HL
38394142 MOV 4139H[C],#42H
43 CMPW AX,BC
444546 CMPW AX,#4645H
47 CMPW AX,HL
48494a MOV 4A49H[BC],A
4b4c CMP A,0FFE4CH
4d CMP A,[HL]
4e4f CMP A,[HL+4FH]
5051 MOV X,#51H
5253 MOV C,#53H
5455 MOV E,#55H
5657 MOV L,#57H
58595a MOVW 5A59H[B],AX
2d SUB A,[HL]
5e5f AND A,[HL+5FH]
482020 MOV 2020H[BC],A
713306 CLR1 P6.3H
712306 CLR1 P6.2H
f528ff CLRB !PM8
f53800 CLRB !PU8
f408 CLRB P8
714206 SET1 P6.4H
715206 SET1 P6.5H
716206 SET1 P6.6H
306400 MOVW AX,#64H
fc9e0900 CALL !!99EH
717206 SET1 P6.7H
717306 CLR1 P6.7H
306400 MOVW AX,#64H
fc9e0900 CALL !!99EH
717206 SET1 P6.7H
30ae00 MOVW AX,#0AEH
fc9f0200 CALL !!29FH
30ad00 MOVW AX,#0ADH
fc9f0200 CALL !!29FH
308a00 MOVW AX,#8AH
fc9f0200 CALL !!29FH
30a800 MOVW AX,#0A8H
fc9f0200 CALL !!29FH
303f00 MOVW AX,#3FH
fc9f0200 CALL !!29FH
30d300 MOVW AX,#0D3H
fc9f0200 CALL !!29FH
f6 CLRW AX
fc9f0200 CALL !!29FH
304000 MOVW AX,#40H
fc9f0200 CALL !!29FH
30a000 MOVW AX,#0A0H <<<--- Segment remap cmd
fc9f0200 CALL !!29FH
30c000 MOVW AX,#0C0H <<<--- Scan direction cmd
fc9f0200 CALL !!29FH
30a600 MOVW AX,#0A6H
fc9f0200 CALL !!29FH
30a400 MOVW AX,#0A4H
fc9f0200 CALL !!29FH
308100 MOVW AX,#81H
fc9f0200 CALL !!29FH
30aa00 MOVW AX,#0AAH
fc9f0200 CALL !!29FH
cf258eaa MOV !8E25H,#0AAH
30d500 MOVW AX,#0D5H
fc9f0200 CALL !!29FH
304000 MOVW AX,#40H
fc9f0200 CALL !!29FH
30d800 MOVW AX,#0D8H
fc9f0200 CALL !!29FH
f6 CLRW AX
fc9f0200 CALL !!29FH
30d900 MOVW AX,#0D9H
fc9f0200 CALL !!29FH
308400 MOVW AX,#84H
fc9f0200 CALL !!29FH
f6 CLRW AX
90 DEC X
fcb40200 CALL !!2B4H
00 NOP
712206 SET1 P6.2H
306400 MOVW AX,#64H
fc9e0900 CALL !!99EH
30af00 MOVW AX,#0AFH
ec9f0200 BR !!29FH
-
Excellent Work David! THANKS
-
Well the new SSD1309 screen arrived and got it swapped out, It looks great but ill have to say the firmware modification is a bit beyond me would it be too much to ask for some more help?
-
First of all we need to find some programming software to make sure we can unbrick it.
Maybe this:
https://github.com/danielnilsson9/78k0r-pgm
-
Hello everyone,
I’m new to programming microcontrollers and could really use your guidance to ensure I’m doing everything correctly. I’ve recently soldered a screen to my multimeter, and I’m seeing the expected mirrored image. Before I proceed with programming, I want to double-check my plan since this is my first time attempting this.
Here’s what I’ve planned so far:
1. Install the PL23XX_Prolific driver.
2. Connect a USB 2.0 to TTL UART adapter to Multimetr
3. Pull FLMD0 to 3.3V to activate programming mode.
4. Run the utility U1253B_Firmware_Update_Software_V304. Do I need any additional software to program the multimeter, or is it sufficient to just launch this utility?
The multimeter will remain powered off throughout the process.
Does this setup look correct?
Thank you in advance for your help!
-
You can skip step 3: it is only necessary if you brick the meter and it will not accept a firmware update.
When the meter works it is just a "normal" firmware update with the only caveat that you have to use the update tools listed since the newer ones check that the firmware is original before flashing...
So it can also be flashed via IR if you have the adapter for it...
-
Thanks for your reply.
Do I really need to install PL23XX_Prolific driver for my USB-to-UART converter?
-
No, you only need a driver that can communicate with the serial converter chip in your unit, I used one by Sparkfun if you look back at my posts here and it worked fine.
-
Thanks for your code and description
-
Thank you to all that researched and produced a working solution for these meters!
I just replaced the display in mine and its back up and working again. I tried a white display which is in it now but I'm not really happy with it. I ordred a yellow on at the same time so I'm going to swap that out.
Regardless, I wouldn't have these options without the good folks in this thread!
Thanks again.
-
I finally became the owner of a U1273A. This Vishay OLED display that has been in my drawer for 5 years finally has a place to use. Thank you David!
-
Thank you all who participated in this epic reverse engineering journey and who share their results in an easy-to-apply package.
You have saved another U1273A from the e-waster bin!
I really love this DMM and I was bummed to see its OLED go dim, but no more...
For reference, I bought this screen, which worked like a charm: https://www.aliexpress.us/item/3256805515059160.html (https://www.aliexpress.us/item/3256805515059160.html)
-
Hi,
I have a U1253A with the modded firmware and I am encountering an issue with the Hold function, at least for DCV measurements: if the reading is above 5V (i.e. beyond the threshold for the first DCV range), after I press Hold, if I then remove the power from the meter inputs, Hold gets automatically disabled.
If I repeat the same sequence, but with a voltage source below 5V, Hold works as intended.
Is this a general U1253A issue (i.e. even with a standard firmware), or is it a consequence of the mod?
FYI, I ran the same test with a U1253B also with the modded firmware, but the Hold function behaves normally on this one.
-
Hard to tell, please go back to original fw and check if t works.
-
I was trying to avoid doing that, but I agree this is the best route.
I've just moved to the original firmware and the issue is still present.
So, I guess it is one of the "features" of the A version of the meter.
I checked with resistance measurements as well, and it is the same behaviour (so, not limited to just DCV).
After playing around more, I concluded the Hold function is being disabled by auto-ranging, when switching between ranges.
If I set a manual range, Hold works reliably irrespective of the readings.
When ranging is set to auto and I enable Hold, if the readings do not go outside the lower or upper thresholds of the range active at the time of enabling Hold, then Hold also works as expected.
It is only when in auto-ranging mode and Hold is activated, and also the readings trigger a change of range (either lower or higher), that's when Hold gets deactivated.
-
To avoid any confusion, this Hold issue conversation is about what Agilent/Keysight call "Refresh Hold" functionality - aka AutoHold, Touch Hold, etc. - which is the default on the U1253A/B multimeters.
If you switch to Data Hold / Trigger Hold - i.e. old-style hold - you are not affected by this problem.
-
Aha! I'm not guilty this time :)
-
Aha! I'm not guilty this time :)
Not this time. :P
And, of course, too focused on the problem, I forgot to thank you and everyone who helped save all these meters.
Thank you indeed!
-
I just opened my brand new U1453A, which I purchased 3–4 years ago, only to find cracked front case parts and a faulty LCD. :palm:
Does anyone have working cooked firmware, or will I need to spend some time figuring it out myself with David's info?
I’d appreciate any tips or clues!
-
First, try replacing the display, some keysight models will work right away.
-
OK David, will update once replaced. Thanks
-
Keep in mind U14xx devices weren't reverse-engineered yet, I posted some bits to disassemble the fw, but that was all.
I won't spend time on it, the work should be done by U14xx owners willing to fix their devices :).
-
No problem, Dave. In this case, it might take me a while with the time i have available. Hopefully, you can provide me with some wisdom once I get stuck.
-
I found a way to disassemble the firmware on 78Kxx devices!
Download "CubeSuite+ for CA,CX" from Renesas (https://www.renesas.com/en/document/swe/evaluation-software-cs-cacx-v40500-single-download) (Requires registration) or Drive (https://drive.google.com/file/d/1zqzHP9Db_V7f1a-1PThDxuJrSigpdqi3), then follow the attached picture.
Loading binaries doesn't work (Throws illegal file error), but Hex does, can be converted with HxD (Export... 32-bit Intel Hex).
The file from U1461A firmware update (U1461A_V302.AG) needs the same byte/nibble swapping as U1273, so use the same tool, then load the output into HxD and export as Hex.
Attached the files for anyone wanting to play with them.
I located the oled initialization at address 0x130
303132 MOVW AX,#3231H
33 XCHW AX,BC
343536 MOVW DE,#3635H
37 XCHW AX,HL
38394142 MOV 4139H[C],#42H
43 CMPW AX,BC
444546 CMPW AX,#4645H
47 CMPW AX,HL
48494a MOV 4A49H[BC],A
4b4c CMP A,0FFE4CH
4d CMP A,[HL]
4e4f CMP A,[HL+4FH]
5051 MOV X,#51H
5253 MOV C,#53H
5455 MOV E,#55H
5657 MOV L,#57H
58595a MOVW 5A59H[B],AX
2d SUB A,[HL]
5e5f AND A,[HL+5FH]
482020 MOV 2020H[BC],A
713306 CLR1 P6.3H
712306 CLR1 P6.2H
f528ff CLRB !PM8
f53800 CLRB !PU8
f408 CLRB P8
714206 SET1 P6.4H
715206 SET1 P6.5H
716206 SET1 P6.6H
306400 MOVW AX,#64H
fc9e0900 CALL !!99EH
717206 SET1 P6.7H
717306 CLR1 P6.7H
306400 MOVW AX,#64H
fc9e0900 CALL !!99EH
717206 SET1 P6.7H
30ae00 MOVW AX,#0AEH
fc9f0200 CALL !!29FH
30ad00 MOVW AX,#0ADH
fc9f0200 CALL !!29FH
308a00 MOVW AX,#8AH
fc9f0200 CALL !!29FH
30a800 MOVW AX,#0A8H
fc9f0200 CALL !!29FH
303f00 MOVW AX,#3FH
fc9f0200 CALL !!29FH
30d300 MOVW AX,#0D3H
fc9f0200 CALL !!29FH
f6 CLRW AX
fc9f0200 CALL !!29FH
304000 MOVW AX,#40H
fc9f0200 CALL !!29FH
30a000 MOVW AX,#0A0H <<<--- Segment remap cmd
fc9f0200 CALL !!29FH
30c000 MOVW AX,#0C0H <<<--- Scan direction cmd
fc9f0200 CALL !!29FH
30a600 MOVW AX,#0A6H
fc9f0200 CALL !!29FH
30a400 MOVW AX,#0A4H
fc9f0200 CALL !!29FH
308100 MOVW AX,#81H
fc9f0200 CALL !!29FH
30aa00 MOVW AX,#0AAH
fc9f0200 CALL !!29FH
cf258eaa MOV !8E25H,#0AAH
30d500 MOVW AX,#0D5H
fc9f0200 CALL !!29FH
304000 MOVW AX,#40H
fc9f0200 CALL !!29FH
30d800 MOVW AX,#0D8H
fc9f0200 CALL !!29FH
f6 CLRW AX
fc9f0200 CALL !!29FH
30d900 MOVW AX,#0D9H
fc9f0200 CALL !!29FH
308400 MOVW AX,#84H
fc9f0200 CALL !!29FH
f6 CLRW AX
90 DEC X
fcb40200 CALL !!2B4H
00 NOP
712206 SET1 P6.2H
306400 MOVW AX,#64H
fc9e0900 CALL !!99EH
30af00 MOVW AX,#0AFH
ec9f0200 BR !!29FH
Woah this is amazing! Opens door to many possibilities if there is someone who owns the DMM and also knows how to read and edit assembly language!
(Sorry for long silence - somehow I was not getting notification emails to this and several other threads - lots to catch up here!)
-
Hi, I use the U1253A today to measure capacitors and the meter it's dead, change the scale up to mF and nothing happens. Any idea? Thanks
Define "dead".
Or is it only failing to scale to mf?
@onesystem could you test this on yours?
Hi! Just saw this. It is not a problem on my meter - if I short leads while in capacitance mode, it cycles through into MF range, obviously trying to measure capacitance; if I measure actual capacitors - it quickly shows me the values (electrolytic and ceramic - no problem). So no sure what happened there... Maybe the capacitor that he was trying to measure was shorted...
-
Got the new screen, but clearly the ribbon pitch is different to the original. Is it normal ???
-
I guess Keysight couldn't even keep the same F---- OLED display between models. Not a good start of this repair
-
I guess Keysight couldn't even keep the same F---- OLED display between models. Not a good start of this repair
Yes, looks like screen model did change from that model to the later one. But not to worry, all of the OLED handheld DMMs are being obsoleted by Keysight now. They leave us with 1280 series that only comes in two models, has LCD segmented displays only - with major advantage of being very fast on measurement refresh rate - 40 readings per second comparing to 7 readings per second.
-
Can you look into U1453A/U1461A, which has the same OLED problems? Would appreciate the efforts if can come up with mod firmware.
-
See post from DavidAlfa that he posted on 4 Nov 2024. Basically he already even found the area where screen initialization is occurring. Maybe you can finish it off and test it, especially if you have the DMM. I only have the U1273AX... So can't test the 1453/1461...
-
Thanks for the advice. However, I'm not very good in programming. Possible to modify the file based on the link here, I can do all the testing.
https://www.keysight.com/us/en/lib/software-detail/instrument-firmware-software/u1453a--u1461a-firmware-2564564.html
-
You're assuming the display won't work, but nobody reported the result of swapping it.
Even the 1273 doesn't need the mod it if it came with v4 firmware.
-
I have a U1453A with dead OLED, I found there is a SSD1305 mark on the module, I replaced it with SSD1325 module, and it showed mirror image, similar to U1253A.
If anyone can modify the firmware to fix this, I would appreciate and wound do the testing.
-
Sorry, mind sharing where you bought the replacement OLED module?
-
I encountered the same issue, the pitch is around 0.8mm only.
-
I encountered the same issue, the pitch is around 0.8mm only.
This is the screen that I got, as in this post:
https://www.eevblog.com/forum/microcontrollers/8-bit-78k0-d78f0547-help-with-firmware-modification/msg5144169/#msg5144169 (https://www.eevblog.com/forum/microcontrollers/8-bit-78k0-d78f0547-help-with-firmware-modification/msg5144169/#msg5144169)
So if your original screen has smaller pitch, it will be a different model/variation.
-
I encountered the same issue, the pitch is around 0.8mm only.
This is the screen that I got, as in this post:
https://www.eevblog.com/forum/microcontrollers/8-bit-78k0-d78f0547-help-with-firmware-modification/msg5144169/#msg5144169 (https://www.eevblog.com/forum/microcontrollers/8-bit-78k0-d78f0547-help-with-firmware-modification/msg5144169/#msg5144169)
So if your original screen has smaller pitch, it will be a different model/variation.
Yes, I was referring to U1453A
-
Look at the original OLED screen and look up the datasheet for it - which should tell you the exact pitch plus pinout (if any different). Then look online at currently available screens for sale, read their datasheets and you will find an OLED that matches the original (that is what I did originally with mine to make sure it will work). If you could post what you found, it will help other people in the future as well.
-
Hi All,
I have a U1253B DMM with a dead OLED, I bought a display with SSD1309, and applies modified firmware and it worked wonders. Kudos to the efforts of the team here.
In the same time, I have a U1453A same OLED failure too. I took the working U1253B display module and placed on U1453A and there is no display. After that, I did some investigation and fixed the problem ( mainly on the voltage shifter section), now the display can turn on, but with mirrored image.
If the original OLED is SSD1303, then it's the expected behavior, as U1253A/B, U1273 etc. but the thing is the original OLED screen carries a mark of SSD1305T7, which is supposed to be compatible with SSD1309 except some column shifting.
Any ideas? What else can I try?
-
I found a way to disassemble the firmware on 78Kxx devices!
Download "CubeSuite+ for CA,CX" from Renesas (https://www.renesas.com/en/document/swe/evaluation-software-cs-cacx-v40500-single-download) (Requires registration) or Drive (https://drive.google.com/file/d/1zqzHP9Db_V7f1a-1PThDxuJrSigpdqi3), then follow the attached picture.
Loading binaries doesn't work (Throws illegal file error), but Hex does, can be converted with HxD (Export... 32-bit Intel Hex).
The file from U1461A firmware update (U1461A_V302.AG) needs the same byte/nibble swapping as U1273, so use the same tool, then load the output into HxD and export as Hex.
>>>>The file from U1461A firmware update (U1461A_V302.AG) needs the same byte/nibble swapping as U1273,
How to do this? The .ag file you uploaded is the original one or after byte swapping?
Attached the files for anyone wanting to play with them.
I located the oled initialization at address 0x130
303132 MOVW AX,#3231H
33 XCHW AX,BC
343536 MOVW DE,#3635H
37 XCHW AX,HL
38394142 MOV 4139H[C],#42H
43 CMPW AX,BC
444546 CMPW AX,#4645H
47 CMPW AX,HL
48494a MOV 4A49H[BC],A
4b4c CMP A,0FFE4CH
4d CMP A,[HL]
4e4f CMP A,[HL+4FH]
5051 MOV X,#51H
5253 MOV C,#53H
5455 MOV E,#55H
5657 MOV L,#57H
58595a MOVW 5A59H[B],AX
2d SUB A,[HL]
5e5f AND A,[HL+5FH]
482020 MOV 2020H[BC],A
713306 CLR1 P6.3H
712306 CLR1 P6.2H
f528ff CLRB !PM8
f53800 CLRB !PU8
f408 CLRB P8
714206 SET1 P6.4H
715206 SET1 P6.5H
716206 SET1 P6.6H
306400 MOVW AX,#64H
fc9e0900 CALL !!99EH
717206 SET1 P6.7H
717306 CLR1 P6.7H
306400 MOVW AX,#64H
fc9e0900 CALL !!99EH
717206 SET1 P6.7H
30ae00 MOVW AX,#0AEH
fc9f0200 CALL !!29FH
30ad00 MOVW AX,#0ADH
fc9f0200 CALL !!29FH
308a00 MOVW AX,#8AH
fc9f0200 CALL !!29FH
30a800 MOVW AX,#0A8H
fc9f0200 CALL !!29FH
303f00 MOVW AX,#3FH
fc9f0200 CALL !!29FH
30d300 MOVW AX,#0D3H
fc9f0200 CALL !!29FH
f6 CLRW AX
fc9f0200 CALL !!29FH
304000 MOVW AX,#40H
fc9f0200 CALL !!29FH
30a000 MOVW AX,#0A0H <<<--- Segment remap cmd
fc9f0200 CALL !!29FH
30c000 MOVW AX,#0C0H <<<--- Scan direction cmd
fc9f0200 CALL !!29FH
30a600 MOVW AX,#0A6H
fc9f0200 CALL !!29FH
30a400 MOVW AX,#0A4H
fc9f0200 CALL !!29FH
308100 MOVW AX,#81H
fc9f0200 CALL !!29FH
30aa00 MOVW AX,#0AAH
fc9f0200 CALL !!29FH
cf258eaa MOV !8E25H,#0AAH
30d500 MOVW AX,#0D5H
fc9f0200 CALL !!29FH
304000 MOVW AX,#40H
fc9f0200 CALL !!29FH
30d800 MOVW AX,#0D8H
fc9f0200 CALL !!29FH
f6 CLRW AX
fc9f0200 CALL !!29FH
30d900 MOVW AX,#0D9H
fc9f0200 CALL !!29FH
308400 MOVW AX,#84H
fc9f0200 CALL !!29FH
f6 CLRW AX
90 DEC X
fcb40200 CALL !!2B4H
00 NOP
712206 SET1 P6.2H
306400 MOVW AX,#64H
fc9e0900 CALL !!99EH
30af00 MOVW AX,#0AFH
ec9f0200 BR !!29FH
-
First of all we need to find some programming software to make sure we can unbrick it.
Maybe this:
https://github.com/danielnilsson9/78k0r-pgm
Keep in mind U14xx devices weren't reverse-engineered yet, I posted some bits to disassemble the fw, but that was all.
I won't spend time on it, the work should be done by U14xx owners willing to fix their devices :).
-
>>>The file from U1461A firmware update (U1461A_V302.AG) needs the same byte/nibble swapping as U1273
Can share how this is done. Don't see the details in U1273 operation.
-
First page...
https://www.eevblog.com/forum/microcontrollers/8-bit-78k0-d78f0547-help-with-firmware-modification/msg5284399/#msg5284399 (https://www.eevblog.com/forum/microcontrollers/8-bit-78k0-d78f0547-help-with-firmware-modification/msg5284399/#msg5284399)
-
Where to download "tool.exe"?
-
Exactly at the bottom of the message I linked earlier.
tool_U1253A.zip
tool_U1253B_U1273A(X).zip
-
Thanks David, Now I'm able to load the correct firmware and managed to change the code, however, now I face a problem, which may ruin the project.
For U1453A/U1461A, there is only one version (3.02) available and the update didn't work as there are some version checking in place.
-
Probably you need to patch the updater exe... Try with Ghidra...
-
For U1453A/U1461A, there is only one version (3.02) available and the update didn't work as there are some version checking in place.
Can you please post screenshots of what exactly happens? It should technically let you load the program. It could be as simple as renaming the file you are loading to match the version of what the loader expects.
-
You're taking many risks, I strongly suggest to find a debricking/programming method before trying any mods
-
You're taking many risks, I strongly suggest to find a debricking/programming method before trying any mods
True. To start with, it would be smart to flash the unmodified stock firmware before loading the modded one. Again, in U1273 version loader was expecting a specific name of the file. So simply renaming any firmware I was able to "force" loader to accept it. Not sure if would be the same with yours.
-
I don't mean that. Modding the fw can lead to hard locking, and unable to enter recovery mode.
So, you need a way to program the mcu at low level.
Also, it seems the .ag file lacks the bootloader, so we don't know what's going on there.
-
Here is what for U1461A:
1. Replace the OLED with SSD1309, it shows mirrored image.
2. Download the official firmware (3.02) and connect to the meter. The meter can be detected and shows version 3.02 as well.
3. Run the update, it completed without error.
4. Restart the meter and it shows the same mirrored image. ---> Until this moment, we don't whether the firmware is replaced or ignored as they are the same revision.
5. Follow the instruction to change a few things in the firmware including A0->A1. replace the original firmware with the modded one with the same name.
6. Run the update program, it didn't brick the system, but seems didn't change the behavior.
So I suspect that maybe it's the same revision, the update program didn't make the change.
-
4. Restart the meter and it shows the same mirrored image. ---> Until this moment, we don't whether the firmware is replaced or ignored as they are the same revision.
5. Follow the instruction to change a few things in the firmware including A0->A1. replace the original firmware with the modded one with the same name.
6. Run the update program, it didn't brick the system, but seems didn't change the behavior.
So I suspect that maybe it's the same revision, the update program didn't make the change.
To remove this suspicion, you can try changing some of the known strings in the meter, like in the settings menu — swap a couple of letters in one of the menu options and see if, after firmware upload, they are changed. DavidAlpha taught me that in the beginning — to ensure that mods were in fact loaded in the meter.
-
Yes, I have tried some strings with no effects at all.
BTW, this is how to replace the firmware file, is it the correct way?
1. Go to C:\Program Files (x86)\Keysight Technologies\Keysight U1453A U1461A Firmware Update Software (Version 3.02) and replaced the "U1461A_V302.AG", then run the update app. ( I did purposely deleted the file, and the update app will complain, indicating it is actual take file from here. )
-
So my original CPLD-based U1253A display replacement ended up not working out due to a PCB design error and the project ended up getting shelved. After finding my box with two of these broken meters in it, I figured I'd check in here - now it's a 100% firmware fix to flip the screen, no custom PCB needed! Great work, folks!
So I transplanted a new OLED screen onto an original multimeter display board, and now have one meter up and running with a backwards display.
But no matter what I try, I seemingly can't get new firmware programmed into my meter.
I'm using a U1173A cable, with the updated PL2303 drivers from the main post in this thread. The cable works - using PuTTY with a spoon as a mirror held up to the optical cable, I can type characters and get characters echoed back. And running the Keysight Handheld Meter Logger software, I can successfully talk to the meter and get readings out of it. Works for a 2nd meter I have which also has a busted display. Images are attached showing the info of both meters successfully read out over the optical cable.
But the firmware update program just shows "NO LINK". I've tried different baud rates on the meter, tried both meters I have, a couple different computers with Windows 10 and Windows 11... no dice. Both the stock and the mod variations show NO LINK, as well as the official program off Keysight's site. Interestingly the meter itself has the "PC" indication come up on the screen when I run the update software (any of 'em) so there's obviously bytes making it from the update program to the meter.
I'm stumped. Anyone else run into this and have any suggestions?
Thanks!
-
Try right click... Run as admin?
-
Didn't work, no difference.
-
I think your meter must be set to 9600 baud for the update program to connect.
-
... and I tried a handful of baud rates too. No worky.
I'm just wondering if it's a Windows 10/11 thing, or if I need to go find a different optical cable or something. Even getting the program to run in the first place meant finding a couple of missing .OCX files so I'm leaning towards "I don't have an old enough computer to do this" being the problem.
I can probably gather up the hardware to try using the 78k0 flash utility over the programming header inside, if there's some guarantee of success doing it that way.
-
Programming header inside works the same way. I used that programming header directly with official keysight update utility to load firmware.
Try uninstalling the utility completely, running ccleaner to remove left over registry files, restarting computer and reinstalling the flash utility newly, with earlier versions of windows compatibility enabled.
You can try doing a fresh install in a virtual machine running a compatible version of Windows - VirtualBox seems to be good to me with COM ports handling...
-
Try changing the port to a low number in the device manager (I.E. COM3)
-
FINALLY GOT IT TO WORK!
I gave up on infrared. I tried the low COM port number, downloaded a serial sniffing program that shows that the upgrade program does query the meter and get a response, but it's just not doing anything with it. I'm guessing there's some bad combination of the upgrade program, the PL2303 driver for my old IR cable and Windows 10/11 going on.
I connected my Bus Pirate to the JST header on the top of the meter, set it to sniff serial, and the thing started spitting out *1 *2 etc when I'd turn the knob. Oooo. I changed the host baud rate to 9600, set the thing up as a transparent serial bridge, fired up the upgrade program, and START wasn't greyed out!
[attachimg=1]
Thanks everyone for doing your bit to get these old meters working, especially with something as simple as a display swap + firmware upgrade. So much easier than my CPLD board idea.
-
I'm guessing there's some bad combination of the upgrade program, the PL2303 driver for my old IR cable and Windows 10/11 going on.
I vaguely recall having a similar problem, but can't remember if it was on Win10 or 11. Either way I think I had to manually find and install the driver. Unfortunately, I never committed this info to permanent storage and it has long since been evicted.