Metcal MX-5200 and MX-5000 firmware and data-EEPROM information thread

[benj38]

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.

[Zucca]

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.

[benj38]

@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.

[benj38]

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!

[benj38]

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".

[ChuckDarwin]

@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.

[ivaylo]

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

[benj38]

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

[BlackICE]

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?

[Zucca]

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_C
MX5000 MX-PS5000 7027_0860_B
Attached the EEPROM readout.

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.

[benj38]

@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.

[Zucca]

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

[benj38]

@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.

[Zucca]

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 

[Zucca]

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

 

[Nixy]

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 

[Zucca]

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.

[mikeselectricstuff]

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

[Nixy]

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 

[Zucca]

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.

[mikeselectricstuff]

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)

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.

[benj38]

@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

[benj38]

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).

[benj38]

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? 

[mikeselectricstuff]

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

[benj38]

@Mike
I could not get the high point to allow me to do anything; the med point gave me maybe one second where it would accept anything, and even for the low point one has to be as fast as a demon to press the button when the displayed power is at a given value. I guess the obvious explanation is that they use a static load instead of a soldering tip for setting this at the factory.

I would have thought that the power draw corresponds to predictable absolute values out of the detection circuit (especially since the bar-graph is just a relative indicator and not a real measurement), and thus there would be no need to calibrate the bar-graph.

That said, some findings from the posts #msg2730662, and #msg2743296 certainly support this conjecture.

[benj38]

After playing with the service menu I can add the following information.

1. The clock (Rtc) option is completely useless: once set, it never advances as time passes, and it is completely forgotten when power is lost. Indeed, the only information about the clock stored in the data-EEPROM is a single bit indicating whether to show it or not.

2. The bit controlling the display of the clock, as well as the bit controlling the two options under the "Comm" menu are stored (together with the bit flagging whether the bar-graph is  "standard"  or "ultrafine" -- see OP) in the low nibble of the byte at address 01, as follows:
  Communication serial mode is stored in bit 1. It is 0 for "On Event" and 1 for "polled".
  Clock display is stored in bit 2. It is 0 for "off", and 1 for "on".
  Bar graph scale is stored in bit 3. It is 0 for "standard" and 1 for "ultrafine"
Thus, for example, if all flags are set the low nibble at address 01 will be 0E.

3. The "Cal" option in the service menu is responsible for all the rest of the data-EEPROM non-zero bytes except for the first 4 bytes. Using a glass of cold water to dip the tip in I managed to draw enough power (readings in the 600s) to allow me to get the option to also set the "Cal Hi Poi..." that eluded me before (see previous message in thread). Note that there was no real way for me to chose a particular number to set as the power-draw was constantly changing, so the calibration was to basically random values in the allowed range.  I Have performed a calibration of all three points (the unit does not save anything unless all points are done together), and then read the data-EEPROM, and then reset it. I repeated this 3 times, with the following results:

00 00 09 01 D6 12 85 3A 5D F4 11 BF 00 00 5C 42
00 00 09 01 45 76 8C 3A CB B0 18 BF 00 00 5C 42
00 00 09 01 48 A4 6E 3A 22 17 03 BF 00 00 5C 42

For comparison, here is the state after a reset:

00 00 09 01 07 16 93 B8 54 20 4E 3E 5F 01 22 C1


Observe that:
 a. Each calibration completely rewrote the values in addresses 04 to 0F.
 b. Addresses 07, and 0B to 0F were written to the same values on all three attempts, thus only 6 bytes are different between different calibrations. This looks reasonable since the number presented on the LCD (and presumably stored) for each of the three points is a 4 digit decimal number (however, the low-point number was less than decimal 100 - which would indicate at least one 00 byte, so the encoding is probably not direct, but translated to the domain of the LCD control).
 c. Addresses 00 to 03 were unchanged - this was to be expected for addresses 00 to 02, but leaves the question open as to what is the 01 at address 03 is used for.

The most interesting point is that a fourth calibration attempt yielded very similar results except that it also wrote FF to address 01, thus completely confusing the unit as to which channel(s) had a hand-piece connected to it.

In summary, it looks like most of the service menu is half-baked, and probably the only useful option is the "reset".

[Zucca]

@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).

Hi Ben,

thanks for the awesome investigation.
My unit is now at 1.36, should I do the test  anyway?

Take care,

Z

[benj38]

@Zucca
Resetting your unit and posting the resulting data-EEPROM was supposed to help us eliminate three options:

• The reset does not erase all the data-EEPROM. If that is the case, then even though you have the same code as me, the reset may not result in the same data-EEPROM.
  
• The reset writes data to the EEPROM that may depend on analog information read from the board which is influenced by the settings of the trimmers on the board.
  
• Data specific to a unit may be present in the code. Thus, even though both you and ChuckDarwin had the same version (1.33), your code is different than his, and thus may yield different data-EEPROM after a reset.
  

I find the third option highly unlikely, and it is the only option that in order to reason about you have to do two resets, one with my 1.36 code you have, and the other with the 1.33 code. The other two options are not very likely, but possible, and can be eliminated if you use the current 1.36 code and a reset yields the same data-EEPROM as mine.

In short, if you have the energy for one reset, use the current 1.36 code; otherwise, do one with the 1.36 code, and another with the 1.33.

[Zucca]

Sure Sir! 

I will be on vacation for the next two weeks, please be patient a little bit. 

[eeviking]

Great thread guys. I just fixed two broken MX-5000's 

One with bar graph not working/showing weird stuff, probably corrupted eeprom data. So it just needed a factory reset. 
Do I need to do a cal after factory reset?

The second one had no output, replacing shorted D12 fixed that. 
It also had some LCD bleeding. Fund a new blue 16x2 display laying around so replaced it while I was in there.
Btw. trimmer RV1 is the display contrast.

Firmware is 1.21 and v1.22 any point in upgrading?

Anyone need a MX-5000? I have a spare 

[benj38]

@eeviking No need to do any calibration after a factory reset. The only data the reset overwrites that was calibrated at the factory is the bar graph display. To calibrate that you need a special load unit, for which we have no specs. Thus, it can only be done at the factory. However, the preset defaults that you get from the reset are pretty good, and the slight loss of accuracy in the bar-graph is really of little importance, as the bar-graph is used almost by anybody as an indicator rather than as an accurate measuring device.

[comka]

Excellent communication,
Who can compare the initial factory calibration and after reset.
And where is this one stored?

[benj38]

Excellent communication,
Who can compare the initial factory calibration and after reset.

Currently, we are waiting for Zucca to do that (I can't since my EEPROM was corrupt when I started this investigation).

And where is this one stored?

I am not sure I am getting your question. The unit-specific bar-graph factory calibration data is stored in the MCU data-EEPROM. This data is overwritten by the reset procedure with default values that, almost certainly, are stored in the flash code (and are thus the same for all units with the same firmware version).

[Zucca]

Firmware is 1.21 and v1.22 any point in upgrading?

I upgraded my MX-5200 from 1.33 to 1.36 and I saw no differences.
The only thing I got was the feeling to have the last firmware.
Who knows what are the differences? 

It looks like the 1.2x are the MX-5000 Firmware, and the 1.3x are  for the MX-5200.

Currently, we are waiting for Zucca to do that (I can't since my EEPROM was corrupt when I started this investigation).

I promise to do the job in the next two days or so.

[comka]

I am not sure I am getting your question. The unit-specific bar-graph factory calibration data is stored in the MCU data-EEPROM. This data is overwritten by the reset procedure with default values that, almost certainly, are stored in the flash code (and are thus the same for all units with the same firmware version).

I was wondering what bits of data were responsible for it.
That's interesting. it is possible to make changes so that the bar-graph is displayed as a percentage. So it’s easier to calibrate it.

Who knows what are the differences? 

There are assumption that 1.36 and 1.37 correct sleep error.
To affirm  I can not, not have an MX-5200.
Didn't want to check the assumption?

[Zucca]

Ah there is a 1.37 FW for the MX5200, good to know.

[cs.dk]

Ah there is a 1.37 FW for the MX5200, good to know.

Yup, there is. Mine is 1.37

[comka]

Ah there is a 1.37 FW for the MX5200, good to know.

Also available... 1.37 FW

[Zucca]

Please forgive my unacceptable embarrassing delay.

Here attached the 1.36 after factory reset.

Can you share the 1.37 FW?

Thanks!

[benj38]

@Zucca, thanks for posting the reset data flash.
Being identical to my data EEPROM after a reset, it confirms all of our conjectures

[prescout]

here is my dumps

[Zucca]

Thanks and welcome prescout!

Which firmware versions have your units?

[anthony_linac]

Although this is about firmware I was also wondering about hardware. I noticed someone stated 1.3 firmware is mx5200 - has anyone found any actual hardware differences between the mx5000 and mx5200? Ie. Is it possible to get both outputs on at the same time with an mx5000 simply by upgrading the firmware? I have just acquired and mx5000 and this thread piqued my interest

[Zucca]

mx5000 simply by upgrading the firmware?

No, otherwise it would be already documented here. They are two different HW.

[Zucca]

Success, upgraded to 1.36 from 1.33!

Just to inform the world that since I did the upgrade I am experiencing an sporadic problem: the tips are sometimes not recognized as original ones.


I am going back to the original 1.33....

[thm_w]

Yeah we don't even have release notes for what changed no? The iron heats up when turned on, thats all I need.

[jeryray]

Anyone know why the MX5200 FW 1.37 does not always remember you last used 2 ports?

I have 5 of these 2x 1.37 that sometimes power up with only port 1 active?

[thm_w]

Anyone know why the MX5200 FW 1.37 does not always remember you last used 2 ports?

I have 5 of these 2x 1.37 that sometimes power up with only port 1 active?

No need to post twice.
OK so you have 5 units, and 2 are 1.37 that lose the setting. But what firmware on the others?
Have you tried the factory reset procedure mentioned above?