Mettler Toledo AG ROM Reverse Engineering  - Page 1
Forum section: electronics / general

author: Rjc987
author_rank: Contributor
timestamp: July 31, 2025, 01:25:45 am
content: Hey everyone!So lately I've been working on a few projects involving hacking the Mettler Toledo AG balances and between taking at least 10 apart, making repairs, and reading the service manual, I've realized the entire line from the lowest AG104, to the highest AG285 share identical weigh cells, boards, chipsets, ROM's software, AND firmware, and that the resolution and capacity is entirely set in software. After playing around I discovered those values are stored in a single tiny 93c56 2k eeprom on the board. I've dumped several of them from across various models, and swapping them swaps the model, resolution, capacity, etc. however I believe the temp compensation table and factory calibration values for the individual weigh cells are also stored on them and while the balance still works even with an eeprom from a different balance, I would imagine the performance would be somewhat compromised.I also just managed to score an essentially unobtanium LC-PT45 "performance tester" - the service I/O interface that mettler techs used to program and calibrate the balances, load replacement pcb's and eeproms with the original values, etc. - which someone mislisted as a standard LC-P45 printer. I haven't played with it yet however the service manual states it has lots of service functions internally in its ROM but that some functions required a service cartridge (just an EPROM board loaded with the service software) be inserted in the balance in place of the standard cartridge so I'm not sure if that will get me any closer to solving things.Basically I just want to determine what values in the eeprom represent the model, capacity, resolution, etc. and which are the values for the cell, if there's a checksum, and how to reprogram any model to maintain the values while modifying the model info. The printouts for the factory data (ag201bd2 is the one labeled 21.10.94, ag201bd3 is the one with the number 3 on it, and ag245 is the last one), and the decompilation result for each from d52, as well as other dumps of the complete firmware/software ROM's of various versions for completeness athttps://drive.google.com/drive/folders/1yTETng-ixm14Zrfv0kD31Wq37QFlohwC- Each is labeled with the model. Any help is appreciated

author: Rjc987
author_rank: Contributor
timestamp: July 31, 2025, 02:31:30 am
content: Just a quick update after finding one puzzle piece, according to the service manualhttp://advatek.myftp.org/manuals/Toledo/Scale%20Manuals/LAB%20Units/RGB_Waagen_e_0903_705116J.pdfpage 378, the configuration is done by entering the model type parameter (TDNR Number, listings for all models start on page 47). Going through the raw binaries, i can see the TDNR numbers are stored at offset 0x16 with the first half of the number last and the last half first. So for the AG245 (TDNR 26115110-26115112) its stored as 51112611, and the AG104's (26210110-26210112) they're stored as 01102621 and 01112621Also I realized I actually misidentified the model numbers for two of the balances - they are AG104's not 201's.

author: abyrvalg
author_rank: Frequent Contributor
timestamp: July 31, 2025, 11:27:58 am
content: Yes, there are multiple checksums in the EEPROM.Checksummed ranges:0x00-0x0F0x10-0x190x1A-0x470x48-0x570x58-0x650x66-0xA10xA2-0xC30xC4-0xDB0xDC-0xFFGeneration algo is: sum all bytes of the range except the last one, add 0x72, negate, store as the last byte.Verification algo: sum all bytes of the range, add 0x72, result must be 0

author: abyrvalg
author_rank: Frequent Contributor
timestamp: August 11, 2025, 10:23:06 am
content: Perhaps my info needs some clarification: I've found (by disassembling AG127 ROM in IDA Pro) that entire EEPROM is broken into several logical areas each one having a separate checksum (see the list). I.e. TDNR is stored at 0x10 together with some other 5 bytes and a checksum byte. I suggest to try transplanting individual logical areas one by one from one model to another until you get the desired effect to find out which one holds the data you are interested in. That would either solve the problem (by identifying a single area that changes the model but doesn't break any calibration) or narrow down the search area significantly. Studying every EEPROM access in disassembly is possible too, but it looks like an overkill for your specific goal.