-
Metcal MX-5200 and MX-5000 firmware and data-EEPROM information thread
Posted by benj38 on 08 Oct, 2019 16:20 -
I was thinking that having a thread where we can share information about the firmware of these soldering stations would be a good idea.
The initial motivation for this came from having a problem with my MX-5200 that was due to corrupt data-EEPROM in the MCU.
I will start with providing some information I have gathered (pertaining to MX-5200 with firmware version 1.36):
1. The MCU is a PIC18F4520-MP, which is a 40-pin DIP plugged into a socket. According to the data sheet this MCU has: 16 bits wide instructions, 8 bits wide data, 32Kbytes code flash memory, 1536 bytes SRAM, and 256 bytes of data-EEPROM.
2. The MCU stores 3 pieces of information in the data EEPROM: (i) the sleep timeout value; (ii) the bar graph scale value; (iii) which of the two channels had a hand-piece connected to it the last time the unit was on.
Items (i) and (ii) are obvious since the user can set them and the unit remembers the set values (even without power).
Item (iii) is used by the unit to look for hand-pieces on next power on. In particular, during the boot sequence the unit does not scan the channels for connected hand-pieces, but simply assumes the remembered state, issuing an "open error" if the actual state does not match the remembered one.
The above data is stored in the data EEPROM as follows (addresses and values are in hex):- Sleep timeout is stored at the low nibble of the byte at address 02; the value is the number of minutes divided by 10. For example, "10 minutes" is stored as 1, and "120 minutes" is stored as C.
- Bar graph scale is stored at the low nibble of the byte at address 01; the value "Standard" is stored as 0, and the value "UltraFine" is stored as 8.
- Channel(s) last used are stored at the low nibble of the byte at address 00, and the high nibble of the byte at address 01, as follows (the first number is the low nibble at 00, the second is the high nibble at 01): left - 0, 0; right - 1, 0; both - 1, 4.
After erasing the data EEPROM to be all zeroes the unit, unsurprisingly, enters a state with sleep timeout of 0 minutes (which is not selectable in the menu), standard bar graph scale, and expecting a hand-piece in the left channel. Interestingly, for some reason it writes the value FF to the bytes at addresses 06 and 0A. These values remain constant regardless of the channels used, or changes to the timeout and bar graph scale settings.
It would be very interesting to know if there is any other info stored in the data EEPROM (I cannot tell since the EEPROM in my unit was corrupt and had to be erased). Thus, if anybody is willing to read their chip and post what they find it would be great.
Looking at text found inside the code flash indicates a potential for some more customization, but I will discuss this in a later post. In any case, I could not find any way to engage a menu where options other then setting the timeout or bar graph scale are available.
- Sleep timeout is stored at the low nibble of the byte at address 02; the value is the number of minutes divided by 10. For example, "10 minutes" is stored as 1, and "120 minutes" is stored as C.
-
Interesting, subbed.
I am wondering if this port on the back could help the process.
Any tips for opening the unit i.e. screw, where to pull/push?
I would like to know what are the difference in the different FW Versions and/or if there are HW versions as well.
-
@zucca:
1. My unit does not have such a port in the back (only a cover over a hole, but nothing underneath the cover).
It would be very interesting if you can open your unit and see what this port is connected to
2. Unscrewing the four screws in the back (security torx T15) allows one to remove the back cover. This gives access to the top side of the power supply board which is attached to the back cover, and the top side of the main board (offering full access to the MCU) which is attached to the middle housing section.
3. After that , if you want, you can remove the two nuts around the output connectors, which allows one to remove the front cover from the middle section, giving access to the bottom side of the main board. -
As promised, here is some more information about the data EEPROM.
My corrupt EEPROM had data in the first 17 bytes out of 256 (the rest were zero) as follows:
FF 00 04 FF 07 FF 93 FF 54 FF 4E 3E 5F 01 22 FF 05
Observe that the first two bytes (FF 00) do not contain a legal encoding of the last channel used, which caused my unit to misbehave.
After erasing all the data, and selecting 20 minutes for sleep timeout, the first 17 bytes became:
00 00 02 00 00 00 FF 00 00 00 FF 00 00 00 00 00 00
The unit came back to life, but the bar-graph on the LCD was not indicating power correctly (only one bar was shown regardless of the power consumption). When restoring the corrupt data (except for the first three bytes), i.e., using:
00 00 02 FF 07 FF 93 FF 54 FF 4E 3E 5F 01 22 FF 05
The unit was again operating properly but this time the bar-graph was constantly showing all bars.
Evidently, some of the data that controls the bar-graph behavior is, for some reason, stored in the data-EEPROM and not in the code flash.
@ChuckDarwin was kind enough to send me a dump of his data EEPROM (firmware ver. 1.33). In his unit everything except for the first 16 bytes is zero, and the first 16 bytes were:
01 08 03 01 07 16 FF B8 54 20 4E 3E 5F 01 22 C1
Note that the first three bytes in this dump indicate that the unit was last using the right channel, that the sleep timeout is 30 minutes, and that the bar graph scale is "UltraFine". Also note that this data matches my corrupt data at addresses 04, 08, 0A, 0B, 0C, 0D, and 0E.
After copying his data (except for the first three bytes) to my unit, i.e., using:
00 00 02 01 07 16 FF B8 54 20 4E 3E 5F 01 22 C1
the unit works as expected and the bar-graph display is also functioning normally!
Can anybody else get a dump of their data EEPROM?
It would be very interesting to compare!
-
Some more information:
As seen from the previous posts, the data-EEPROM stores (in the first three bytes) info about the last channel(s) used, the sleep timeout, and the bar graph scale. It also stores (in the next 13 bytes) information that controls the bar graph display in some way. It may be the case that these 13 bytes also contain some other information.
The code flash contains strings that indicate the possibility of calibrating the unit, hinting that some of this may be calibration data.
While the tip temperature is controlled by the magnetic properties of the tip itself, and needs no calibration,there may be something else going on. In any case, here are some of the more suspicious strings I see in the code:
"Factory Reset", "Good Cal", "Bad Cal", "Cal Low Point", "Cal Med Point", "Cal High Point", "Accept", "Bad", "Pres&Hold", "On Event", "Polled", "Serial Mode", "Exit", "Reset", "Rtc", "Comm", "Cal", "To reset", the names of the months of the year and the days of the week, "VER-TEMP" and "TEMP-ERROR".
-
@benj38 - your settings interpretation from the eeprom data is correct.
Photo of the port connection on one of the 5000 units (the 5200 PCB looks like a minor respin to accomodate the second relay and an add-in current sense board).
The trace from jumper JH2 is a ground. The rear port is a RJ 6 pin keystone jack.
Rear port is marked as "Future Use" in the 5200 unit manual.
It seems unlikely the port is used for data collection/verification as that would eat into Metcal's Verification product line. However, the two 5000 units I've seen with ports also have the DS1305N clock, battery, and MAX478E(*) installed which leans towards data and management and less toward service.
(*) The chip is in U11 just under the right side of the LCD with "thermistor" silkscreened next to it. Hard to read the marking on mine, but I see "MAX478E ESA" which would be an opamp. Present on the 5000 units with ports, missing on my portless 5200 unit, different configs but different models as well.Code: [Select]Facing RJ port, left to right:
RJ J5 Color (in this instance)
1 n/c
2 --- 2 Yellow
3 --- 4 Red
4 --- 3 Green
5 --- 2 Yellow
6 n/c
J4 and J5 share the ground trace, but otherwise do not share the other pins. The J4 et J5 traces are on an interior PCB layer and did not appear on the PIC pins when I raked the pins. There is a conformal coating to be removed and test again to be sure.
For fun, EEPROM 0-15 from the 5000:
00 40 01 08 16 93 38 56 20 4E 3E 60 D1 22 C1 00
@zucca, do you know if your unit has the DS1305N and battery and possibly the MAX478 chip? If you look at the front PCB from the top, you will see the battery blob. Missing MAX478 would show the solder mask for an SOCI-8 footprint.
Someone here must be in a lab or production house that can identify the port use.
-
The manual calls the port on the back Communication Port “For Future Use” - https://www.okinternational.com/File%20Library/Metcal/Resources/User%20Manuals/MX-5000-User-Manual-ML.pdf
-
Currently we have only one example of what the data EEPROM should look like in a good unit.
If we can get more examples it can greatly help in directing the hacking efforts
-
If it isn't locked can't you read the code out and disassemble it to get a better idea of what's going on?
-
benj38 and ChuckDarwin you are doing a wonderful job.
Time to give back something to the community.
I have the following units:Code: [Select]MX5200, SN 032420, DATE 2013-07-18, FW 1.33
MX5000, SN 028310, DATE 2012-12-15, FW 1.22
both units have no rear RJ port.
The two units have the same PSU board:
The flapping in the breeze T0 220 device
is not a production error since it is present in the two units.
I have no DS1305N ,battery or MAX478 in none of the two:
To open the back cover you need a long TX15 Security bit, I manage to get it open with a regular size bit but it was dirty job.
My blood pressure went high and I ordered this to calm me down.
Once the back cover is removed, hello Mr. PIC:
with a 90° Tool I gently lift it up and read it out. Some pins bent, but nothing serious: BE CAREFUL!
Here the versions of the front board (where the PIC is) printed on the top corner on the left side looking from the top:Code: [Select]MX5200 7027-1530_CAttached the EEPROM readout.
MX5000 MX-PS5000 7027_0860_B
I would like to upgrade my 5200 to 1.36, I hope it could be done.
Anyone with a MX5000 with FW>1.22?
Enjoy.
-
@zucca
First, thanks!
Second, my 5200 also has the flapping TO220
, and no DS1305N ,battery, or MAX478.
Third, can you please also post the data-EEPROM? your zip file only contains the firmware flash code.
-
Sorry I am out this weekend. Monday I will sent you the eprom, BTW how do you read the eprom out with the tl866?
Typed on my stupid phone
-
@zucca
There are three pieces of information one can read from the MCU: flash code, data-EEPROM, and configuration bits.
In the "Read Chip" dialog of the TL866 software, these options are called "CODE Memory", "DATA Memory" and "Con.FUSE Bit", respectively.
After you read the chip, and are back in the main window, you will see three tabs, under the heading "Buff select" (buffer select). By default, the "Code Memo" tab is selected, but you can switch to see the data-EEPROM by clicking the "Data Memo" tab, and the configuration fuses by clicking the "config" tab. Also note that when you save the data to a file you get different behavior depending on the type of file you save to. If you save to a binary file (*.bin), it only saves the currently displayed buffer; while if you save to an Intel hex file (*.hex), it saves the data of all three buffers (code, data, and config bits).
BTW, the configuration bits are displayed as check-boxes, with a checked box representing that the bit is "programmed". Programmed bits store a 0 value, and unprogrammed ones a 1 value, so it may be a bit confusing.
-
ben your explanation is idiot proof. I had no chance to do it wrong...
Enjoy the attached EEPROM, I hope my values will confirm your findings.
Let me know what are your board versions, just for sanity check.
Can't wait to upgrade my soldering iron
-
Success, upgraded to 1.36 from 1.33!
I had first to flash the 1.36 code
but the "Erase befor." options did erase all the EEPROM... so I had to restore it from the 1.33 HEX file:
Please share your MX-5200 FW if it is above 1.36, or 1.22 if MX-5000
-
Hi
I scored an MX5000 from eBay with a power bar graph that didn’t respond even though the iron heated up correctly.
I found there was a service menu you could access by pushing and holding down the command/selector push button on the front before turning the unit on via the power switch at the top.
Once inside that a variety of options were available, including “Factory Reset” which when run fixed the bar graph so it’s now working 100% as expected.
In a funny way I have to admit I was disappointed there wasn’t more wrong with it
-
Once inside that a variety of options were available, including “Factory Reset” which when run fixed the bar graph so it’s now working 100% as expected.
Welcome Nixy to this mad place!
Congrats!
I bet my ass it is just resetting the EEPROM that "FACTORY RESET"...
If only benj38 would have known...
Anyway any interesting FW on your MX5000?
EDIT: Service menu works in the 1.22 MX5000 and 1.36 MX5200. -
The firmware on these doesn't do much - certainly not enough to warrant the size of PIC used!
Only two things I can think of that would be useful improvements - disable auto powerdown completely, and auto-reset from a "load error" condition
-
Honestly?
My first impression was the 2 line LCD looked a bit gimmicky, I’m not really sure what it’s bringing to the party other than novelty (and another thing to break)
Certainly other than the wattage jump I can’t see a huge benefit functionality wise from the older MX-500P myself.
Having fixed a few of the 500P models i hope the design has improved, the Wika caps and that ZTX heatsinked TO92 part seemed to be the week points, on the new 5000 model I’ve read the freewheel diode on the 5V buck regulator (same pcb side as the front lcd, near the bottom) are popular to fail.
Nice to have a new bit of tech though
-
The firmware on these doesn't do much - certainly not enough to warrant the size of PIC used!
Only two things I can think of that would be useful improvements - disable auto powerdown completely, and auto-reset from a "load error" condition
At least that huge PIC sits on a socket and it is not soldered down.
Another improvement could be an external trigger for a fume suction box. -
Honestly?
The LCD is useful for diagnosing faulty or failing tips. A common failure mode is that the heater develops intermittant shorted turns, and in the early stages a tap can often bring it back to life. An RGB LED, or a few LEDs in a bargraph could probably give the same info though.
My first impression was the 2 line LCD looked a bit gimmicky, I’m not really sure what it’s bringing to the party other than novelty (and another thing to break)
-
@Nixy great discovering that service menu!
Unfortunately, it probably would not have helped me. I have tried the same procedure with my corrupt MCU, with the hope of resetting the unit or entering a service menu, and it did not work (when there is only one push button, how many non-crazy ways do you have to try to reset the thing?); however, maybe I did not press long enough. I never thought of trying again with the new MCU
-
The story is starting to become interesting
Currently, we have three samples of the 5200 data-EEPROM:
mine (corrupt) FF 00 04 FF 07 FF 93 FF 54 FF 4E 3E 5F 01 22 FF 05
CuhckDarwin's 01 08 03 01 07 16 FF B8 54 20 4E 3E 5F 01 22 C1
Zucca's: 00 08 02 01 20 14 8E B7 EC D8 14 3E 70 CD 8B BF
Ignoring the first three bytes (which we know from the OP what they encode), notice that my corrupt data is equal to ChuckDarwin's except where there is an FF, while Zucca's is completely different than both.
Now, here is my data after first programming it to all zeros, and then using the factory reset from the service menu:
00 00 09 01 07 16 93 B8 54 20 4E 3E 5F 01 22 C1
Observe (again ignoring the first 3 bytes) that it is equal to my corrupt data after replacing every FF in it with the corresponding value from ChuckDarwin's data (and zeroing out the 17th byte).
In fact, the reset makes my data equal to ChuckDarwin's except at address 06 (where his is FF and mine is 93).
This indicates that the data-EEPROM probably does not store any factory calibration data that is specific to the board, though we still need to investigate the 93 vs. FF.
@zucca, do you mind resetting your data using the service menu and posting the result? It is quite curious why your data is so different than ours (I remind you that ChuckDarwin has firmware 1.33 like you did). -
I will try to play with the service menu and see how changes in it are stored in the data-EEPROM. I will report my findings when I am done.
In the meantime, does anybody have an idea what does the "Cal" option in the service menu do?
The menu contains the options: "Cal", "Comm", "Rtc", and "Reset".
"Reset" prompts one with "Factory Reset" "Press&Hold:Reset", and does what one would expect.
"Cal" presents a sub-menu with three options: "Cal Low Poi 0000", "Cal Med Poi 0000", and "Cal High Po 0000". When there is no hand-piece connected, all three options show in the second line: "Press&Hold:Bad", and ignore any attempt to change this value. However, when there is a hand-piece connected (to the channel the unit is currently set to), the number 0000 is constantly changing, indicating the power drawn by the hand-piece. When the value falls below about 200, the "Cal Low Poi..." second line changes to "Press&Hold:Accept", and a long press actually looks like it accepts something. For the "Cal Med Poi.." the "Press&Hold:Accept" appears when the power is above 300 (and below some threshold I could not quite see since it changes too fast). As for the "Cal High Po..." I could not get it to display "Press&Hold:Accept" even when connecting a very power-hungry tip (a 10mm de-soldering tip).
Comm displays a sub-menu titled "Serial Mode" and allows toggling between the options "On Event" and "Polled".
Rtc displays a sub-menu allowing one to (surprise, surprise
) set a clock, and control whether it is displayed or not (when set to display, it appears in normal operation on the second line of the LCD when the unit idles). The funny thing is that it only accepts years in the range of 2000 to 2015
So far so good. It looks like the service menu accounts for almost all the interesting strings found in the code (see #msg2730678).
However, the "Cal" menu with its low, medium and high points is a bit of a mystery. Does anybody have an idea what that is all about?
-
My guess would be it's for scaling the bargraph
However, the "Cal" menu with its low, medium and high points is a bit of a mystery. Does anybody have an idea what that is all about?