-
Dim OLED Screen replacement for Agilent Keysight U1253A U1253B U1273A U1273AX
Posted by onesystem on 31 Oct, 2023 01:26 -
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 (Or search for "SSD1309 8080").
- 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, U1273AX .
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.
Recovery
If something goes wrong, it's pretty easy to recover using a usb-serial converter, read the messages starting here.
-
Looks like the column shift by +2 is here:Code: [Select]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
-
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.
This first bytes:Code: [Select]A0 13 00 00 03 7F 06 7F
Are the actually the last bytes of the firmware:Code: [Select]F7 60 F7 30 00 00 31 0A
A tool was writen to perform this task: (Attached, including the sources).
Usage is as follows:Code: [Select]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:Code: [Select]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:Code: [Select]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:Code: [Select]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!)Code: [Select]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:Code: [Select]- 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).Code: [Select]tool.exe U1273AX_V303.AG fw.bin
Once decoded, it can be partially disassembled after slightly modifying K0dasm (Attached).Code: [Select]k0dasm fw.bin > disassembled.txt
Useful links:
- 78K0 instruction manual.
- Very useful assembler example in k0dasm repo: testprog.asm.
With all this, the essential routines were identified:Code: [Select]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 9a 20
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).Code: [Select]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).Code: [Select]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.Code: [Select]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:Code: [Select]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:Code: (0x7E80) [Select]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 0ACode: (0x7F60) [Select]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:Code: [Select]- "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:Code: [Select]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 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:Code: [Select]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:Code: [Select]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/
- 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!Code: (sub_0b20 (Display position)) [Select]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 skipCode: (sub_0994 (Display init)) [Select]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:Code: [Select]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:Code: [Select]call pattern:
oled_init: sub_7f60 9a 60 7f
oled_draw: sub_7ee6 9a e6 7e (Also calling sub_7eac)
oled_pos: sub_7eac 9a ac 7e
- Display init: sub_7f60:Code: [Select]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_05d1 ;7f99 9a d1 05
movw ax,#0x00ad ;7f9c 10 ad 00
call !sub_05d1 ;7f9f 9a d1 05
movw ax,#0x008a ;7fa2 10 8a 00
call !sub_05d1 ;7fa5 9a d1 05
movw ax,#0x00a8 ;7fa8 10 a8 00
call !sub_05d1 ;7fab 9a d1 05
movw ax,#0x003f ;7fae 10 3f 00
call !sub_05d1 ;7fb1 9a d1 05
movw ax,#0x00d3 ;7fb4 10 d3 00
call !sub_05d1 ;7fb7 9a d1 05
movw ax,#0x0000 ;7fba 10 00 00
call !sub_05d1 ;7fbd 9a d1 05
movw ax,#0x0040 ;7fc0 10 40 00
call !sub_05d1 ;7fc3 9a d1 05
movw ax,#0x00a1 ;7fc6 10 a1 00 <<<--- Segment remap cmd (Y-mirror)
call !sub_05d1 ;7fc9 9a d1 05
movw ax,#0x00c0 ;7fcc 10 c0 00 <<<--- Scan direction cmd (X-mirror)
call !sub_05d1 ;7fcf 9a d1 05
movw ax,#0x00a6 ;7fd2 10 a6 00
call !sub_05d1 ;7fd5 9a d1 05
br !lab_0575 ;7fd8 9b 75 05 <<<--- Continue in original function
- Drawing: sub_7ee6:Code: [Select]sub_7ec0:
push hl ;7ee6 b7 <<<--- Same as original function
push ax ;7ee7 b1
push ax ;7ee8 b1
movw ax,sp ;7ee9 89 1c
movw hl,ax ;7eeb d6
mov a,[hl+0x0a] ;7eec ae 0a
inc a ;7eee 41
mov [hl+0x0a],a ;7eef be 0a
mov x,#0x00 ;7ef1 a0 00
xch a,x ;7ef3 30
push ax ;7ef4 b1
mov a,[hl+0x08] ;7ef5 ae 08
mov x,#0x00 ;7ef7 a0 00
xch a,x ;7ef9 30
call !sub_7eac ;7efa 9a ac 7e <<<--- Call new oled position function
br !lab_0643 ;7efd 9b 43 06 <<<--- Continue in original function
- Set position: sub_7eac:Code: [Select]sub_7eac:
push hl ;7eac b7 <<<--- Same as original function
push ax ;7ead b1
movw ax,sp ;7eae 89 1c
movw hl,ax ;7eb0 d6
mov a,[hl] ;7eb1 87
xch a,x ;7eb2 30
mov a,[hl+0x06] ;7eb3 ae 06
movw hl,ax ;7eb5 d6
mov a,#0xb0 ;7eb6 a1 b0 <<<--- Row cmd
or a,l ;7eb8 61 6e
mov x,#0x00 ;7eba a0 00
xch a,x ;7ebc 30
call !sub_05d1 ;7ebd 9a d1 05 <<<--- Send cmd
mov a,h ;7ec0 67 <<<--- Move column value to reg A
cmp a,!mem_7eca ;7ec1 48 ca 7e <<<--- Compare with subtract value at 0x7eca
bnc lab_7ec9 ;7ec4 9d 03 <<<--- If carry set, load A with subtract value so it becomes 0 when subtracting
mov a,!mem_7eca ;7ec6 8e ca 7e
lab_7ec9:
sub a,#0x02 ;7ec9 1d 02 <<<--- Subtract 2 to column value
mov h,a ;7ecb 77 <<<--- Update H reg for later use in lower column cmd
and a,#0x0f ;7ecc 5d 0f <<<--- Isolate lower column data
mov x,#0x00 ;7ece a0 00
xch a,x ;7ed0 30
call !sub_05d1 ;7ed1 9a d1 05 <<<--- Send cmd
mov a,h ;7ed4 67 <<<--- Move column value to reg A
ror a,1 ;7ed5 24 <<<--- Rotate 4 bits to the left to get higher column bits
ror a,1 ;7ed6 24
ror a,1 ;7ed7 24
ror a,1 ;7ed8 24
and a,#0x0f ;7ed9 5d 0f <<<--- Isolate higher column data
or a,#0x10 ;7edb 6d 10 <<<--- High column cmd
mov x,#0x00 ;7edd a0 00
xch a,x ;7edf 30
call !sub_05d1 ;7ee0 9a d1 05 <<<--- Send cmd
pop ax ;7ee3 b0
pop hl ;7ee4 b6
ret ;7ee5 af <<<--- Done, return
Hex bytes:Code: (0x7EAC) [Select]B7 B1 89 1C D6 87 30 AE 06 D6 A1 B0 61 6E A0 00 30 9A D1 05 67 48 CA 7E 9D 03 8E CA 7E 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 AC 7E 9B 43 06Code: (0x7F60) [Select]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 A7 04 0A 0D 0B 0D 10 0A 00 9A A7 04 0A 0D 10 AE 00 9A D1 05 10 AD 00 9A D1 05 10 8A 00 9A D1 05 10 A8 00 9A D1 05 10 3F 00 9A D1 05 10 D3 00 9A D1 05 10 00 00 9A D1 05 10 40 00 9A D1 05 10 A1 00 9A D1 05 10 C0 00 9A D1 05 10 A6 00 9A D1 05 9B 75 05
Because the entire firmware can't be disassembled, a manual pattern search and replace was performed:Code: [Select]- "9A F5 04" (call !sub_04f5) -> "9A 60 7F" (call !sub_7f60)
- "9A 2C 06" (call !sub_062c) -> "9A AC 7E" (call !sub_7eac)
- "9A 8A 06" (call !sub_068a) -> "9A E6 7E" (call !sub_7ee6)
Patching offsets: ( .AG file in updater format, not reversed)Code: [Select]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)
If for whatever reason, instead subtracting you want to increase the column address, patch as following:Code: [Select]0x18162 Replace [D1 E7 E9 E8 30 D9 E7 E9 84] with [D0 00 00 00 00 00 00 00 00].
Address Value Function
0x18161 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.Code: [Select]: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):Code: [Select]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]Code: [Select]: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)Code: [Select]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)Code: [Select]Address Value Function
0x7FCD 0xC0 / 0xC8 X-mirror off / on
0x7FC7 0xA0 / 0xA1 Y-mirror off / on
0x7ECA 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:Code: [Select]0x7EC1 Replace [48 9E 7E 9D 03 8E 9E 7E 1D] with [00 00 00 00 00 00 00 00 0D].
Address Value Function
0x7ECA 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/
- 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.
If not available anymore, it's also attached.
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
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!
.
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
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 -
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:Code: [Select]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/
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), then install pyserial by opening a command prompt and typing:Code: [Select]pip install pyserial
Download 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)Code: [Select]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!Code: [Select]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
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?".
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 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 anyways.
-
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...
.
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/ . -
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. <<<
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.
-
Completely missed that.
The "common" side which is shared with SW1-SW4 goes to Pin 34 P73/KR3.
-
Yes!
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.
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. -
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.
-
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!Code: [Select]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:Code: [Select]
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)
-
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:
Finally loaded the "U1273AX_V301_failsafe_p74.ag" on meter. Meter works fine, no problems at all.Code: [Select]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)
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
-
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 anyways
Just for reference, I also forked it at 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!
Great thanks to you guys working on thist project！my meter is now back to live again.
- Buy the display: Aliexpress (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, U1273AX .
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.
Recovery
If something goes wrong, it's pretty easy to recover using a usb-serial converter, read the messages starting here.
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.
-
THANKS A LOT!!!!!!!!
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? -
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?
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