Weller Soldering Iron WES51

[Ian.M]

No. Human readable formats like HEX dumps are rarely useful for programming MCUs.

You'd need it in IntelHEX .hex file format, with either the CONFIG bits (aka: 'Fuses') address included in the file, or with notes on how CONFIG word was set.  However I have typed a few lines  of the hex dump manually into MPLAB 8 program memory window and it does look like PIC machine code and disassembles to something vaguely sane, so odds are your programmer is reading the PIC properly, and it isn't protected. 

N.B. The PIC12CE673 contains a 16 byte data EEPROM internally connected via an I2C bus to GPIO pads that aren't brought out of the package, and this data memory is only accessible to application code (firmware), not to an external programmer,  so any copy of the chip *MAY* require a special procedure (possibly a full factory calibration in the station, possibly something else in some sort of test jig)  to properly initialize that data memory.

The IntelHex file could be reconstructed from the hex dump, but that's tedious and error prone compared to simply saving it from your programmer software.  If it cant save IntelHEX (unlikely), what formats can it save?

[bostonman]

This is disappointing.

I thought extracting the data was enough and would be able to burn more along with contributing to others who need it.

I’ll look at other formats when I get home, but I checked all the drop downs menus and only saw a way to save the buffer which was txt format.

[bostonman]

All I can find is the option to save the buffer and it automatically fills in .txt.

Obviously I can stick in my own extension (and maybe that's what is required to save it as a different format), but I'm guessing without extracting it a specific way, saving it with such an extension will be useless.

I apologize in advance, but although I understand your explanation, it also seems a possibility exist I can burn this buffer text dump to a blank PIC and it may work.

Is this what you're saying, or is it basically a useless attempt?

Does any way exist to extract everything from this PIC or did I waste my time removing it?

[Ian.M]

What device programmer do you have, and what software are you using with it?  We can probably figure out how to save a hex file, or at the minimum a binary file + tell you how to read and record the CONFIG word.

I'd give reasonable odds that reading the PIC and writing a blank one will work.   As I noted its not a certainty due to the inaccessible EEPROM, but that has to have been initialized somehow and as the PIC12CE673 is an OTP device^*, (i.e. is not erasable) its highly probable the init code for it is present somewhere and just has to be triggered.  How to do so can be figured out by disassembling the code, + some reverse engineering.

* unless you've got the vanishingly rare, expensive and long obsolete PIC12CE673/JW windowed side brazed CERDIP package, which can be UV erased.

[bostonman]

To be respectable and not double post, I'll reference a thread I started regarding the programmer:

https://www.eevblog.com/forum/projects/pic-programming-question/

If trying to reverse engineer is time consuming, then it's probably not worth it. I question whether my PIC is working correctly, or if it's doing some checks that are preventing it from blinking the green LED due to trying to hack in a phantom iron.

If it's damaged in the sense that maybe the program is fine, but the output driver pins are damaged, then I'd strive to get the program onto another PIC. If it's good, then trying to get the code isn't important (to me) but for the benefit of others, if this PIC code is good, I'd feel good knowing I contributed the code to everyone.

Sooner or later I'll just pull the trigger and buy a new iron. I just question why the PIC isn't blinking the green LED and questioning whether I could have shorted two pins when taking measurements and blew a pin driver.

[Ian.M]

Hmmm.....  The manual, section '4.1.1.2 Save' says that when saving, its supposed to pop up a filetype dialog after you've entered the file name.  Try entering a name with the extension .hex and see if it does.

If the hex file can be saved, it can be loaded into MPLAB 8, disassembled and studied to determine what the LED is meant to do.

[bostonman]

I saw that.

The software has two 'save' sections. One is in the top tool bar under 'buffer' (edit and save buffer are the two main options with encrypted table, e fuse, and vector table, grayed out), and then a 'save' icon.

The 'save' icon seemed to do something different and why I didn't use it. The options it gives as a save type are: binary, Intel, Motorola, Tektronix, and Extend Tektronix.

[Ian.M]

Well there you are.  Intel - short for IntelHEX is the one you want.   

[bostonman]

I feel like an idiot.

Why the heck do they have two different save features is beyond me. The 'buffer' drop down menu I thought was to save the buffer (the actual program extracted from the chip), and, when I saw the other, I thought it was something other than dealing with the downloaded PIC program.

I"ll (hopefully) get the IntelHEX stuff saved later and repost what I got.

[bostonman]

I just re-read the PIC.

Although only Intel was needed, I saved them under every drop down type (named accordingly) possible just in case including saving the buffer text file.

I'll have to dig deeper into understanding the saving options in this burner. When I initially saw the option to save as Motorola, Intel, Tektronix, etc... I thought it was a way to convert to different PIC manufactures and didn't have anything to do with the actual 'buffer'.

Hopefully this extraction is enough to allow another PIC to be created and will benefit others as well.

Edit: forgot to mention, don’t know if it matters, but the window showed: save data size 4010

[Ian.M]

The IntelHEX format file, renamed with extension .hex and imported into MPLAB 8.92 looks OK, includes the CONFIG word, and you can inspect the program memory in symbolic disassembly mode.

There are 810 lines of actual code, which make use of Timer 0, the 8 bit ADC and the internal I2C EEPROM (on internal I/O pads GP6 and GP7).   Oddly enough there isn't a single RETURN or RETFIE instruction (it uses RETLW 00), so I suspect the code was (badly) ported from code for a PIC12F5xx 12 bit core device.   If you want to dig further into its operation we'll probably have to do some serious work to generate a symbolic disassembly that's MPASM compatible for reassembly and builds a byte-identical image, that we can then go through naming variables and subroutines and annotate as we figure out the I2C and control routines.  If we did that, porting to a newer PIC wouldn't be *MUCH* harder. 

At address 0x32E there's a copyright message: "C Cooper Ind. 08/02/2000 V7.5", with the upper part of each word zeroed, not null terminated.

One key thing to note, is it appears your programmer may not preserve the factory OSCAL value, so for correct operation you must read the new PIC *before* attempting to program it and note the value at address 0x3FF, then after loading the saved firmware to the buffer, patch 0x3FF from 3488 (hex) to the value noted for the new PIC.  The 34 bit will stay the same as 0x34nn is the RETLW opcode.  You should then be good to burn the new PIC, but remember you only get one shot at it per new PIC as the PIC12CE673 is OTP, so not erasable.

[bostonman]

but remember you only get one shot at it per new PIC as the PIC12CE673 is OTP, so not erasable

Ouch. This explains why I didn't see the number of burns in the datasheet. I thought all PICs were able to be reprogrammed until now.


From what I understand, are you saying this code doesn't appear corrupt? I ask this not only for myself, but anyone else who will read this and/or need to burn a new PIC due to a broken iron (obviously the files are posted, so others will be downloading them).

If this code isn't corrupt, then I don't understand why the LED isn't blinking (or turns off when I decrease the temperature knob after the iron gets quite hot) unless there is something that detects the iron plugged in. Personally I don't see how it can detect the iron is plugged in by the heating element (remember I have a k-type thermocouple soldered onto the board, so it thinks it has an iron). Unless it pulses the iron heater to get it up to minimum temp and reads the thermocouple. If it doesn't have some sort of precise feedback, then the PIC doesn't perform the same.

The only other idea I have is that the PIC is healthy enough to have the code read, but the output drivers are damaged.

Trying to get the thermocouple up to a specific temperature and measuring the heating plate I try mounting it to correctly is quite hard. I've taken the thermocouple that's soldered on the iron PCB, taped it with Kapton tape to a heating plate, mounted a second thermocouple to a temp meter, and tried tricking the soldering station to think it's really heating to 350 degrees. The issue is the tape doesn't stick and my thermocouple has melted insulation.

Apparently you're experienced with reading PIC code because other than seeing the same thing you mentioned (C Cooper....), I don't know what any of the code means.

Personally I think dissecting the code would be cool and beneficial for being able to burn different PIC models for the future needs of others, but clearly it's not worth the trouble.

For my own curiosity, can you explain how you'd dissect a single line so maybe I can take a crack at digging into it?

As for programming, you said to 'read' a blank PIC and note the address at 0x3FF. Ignoring for the moment that I'm not seeing a line of 0x3FF (it goes from 0x3F0 to 0x400), I assume the steps I need to take are:

Insert the blank chip and read the information stored on it (I wasn't aware a blank PIC could be 'read')

Scroll down to 0x3FF and note the address from where on that line? Maybe provide an example from the current code to clarify how to read an address?

I'm sure this is unique to the programmer, but I've never programmed a chip that required any change to a starting address, it's always been take this HEX file and press burn (or similar steps when burning FPGAs). How do I tell the software to start burning at a specific address?

Not knowing anything about PICs, I'm uncertain the need to start burning at a specific address or can visualize what it would mean to start a specific address. From the way it looks with the current program, it starts at address 0x0000, but I'm uncertain if this is just the line number or an address (or if I'm just mixing up the two).

[Ian.M]

I said "" ... note the value of address 0x3FF ...". To clarify, I mean " ... note the contents of the address 0x3FF ...".

That address holds a RETLW opcode with a data byte that holds the 'factory' oscillator calibration.  It gets copied to the OSCCAL register by the firmware shortly after startup.  If its corrupted, the PIC may run too fast or too slow, which could possibly result in unexpected behavior. 

Don't expect the adhesive on Kapton tape to stay stuck to a heated surface.  You need fibreglass sleeving or close weave glassfibre ribbon or cloth to electrically insulate the thermocouple, saturated with non-conductive heatsink compound for reasonably good thermal transfer + some sort of resilient mechanical clamping arrangement, to maintain pressure without breaking the thermocouple.  It may be easier to do it 3D printer hotend style in a drilled hole in a hot block with a tapped hole for a retaining screw to hold a washer clamping the sleeved leads right next to it.

To understand PIC machine code, you need a thorough understanding of PIC assembly programming so you can sight- read the disassembly listing without having to continuously refer to the datasheet for every instruction.  It comes with practice and plenty of hours working on projects in assembly language, and is not something that can be taught easily online. 

[bostonman]

This is all I see. Think I'm missing something.

000003E0  27 02 03 18 41 2A 27 08-B7 00 37 08 A2 00 01 30
000003F0  A1 00 08 20 A0 1F F5 29-41 2A B0 1F D2 29 41 2A
00000400  AF 1B FD 29 BE 0A 04 30-3E 02 03 1D A3 29 AF 17 

[Ian.M]

Midrange PICs use a 14 bit core i.e. every single word instruction is 14 bits long.  14 bits cant fit in a byte so every program memory word takes up two hex bytes (4 ASCII characters) in the hex file.  Hex file addresses are thus double the actual PIC address.  Your programmer software isn't smart enough to know about this address doubling, so you need to look at data buffer addresses 0x7FE and 0x7FF, which should be on the last line right at the end, which hold the RETLW in question, low byte first. 0x7FE is the one that will need patching, and 0x7FF should *ALWAYS* be 34 hex (for this PIC).

[bostonman]

I just realized you must have edited your message.

When I read this yesterday, I don't remember seeing as much typing, and now I'm looking again and see it has a 'last edit'.

Just wanted to clarify in case my response seemed as if I was asking the same question over.

I may buy a few PIC chips to see if I can program them the way you're suggesting. I need to order some components, a new iron, and replacement pins for the soldering iron connector (one of the heater wires broke off the pin from moving around the PCB).

[Ian.M]

I just realized you must have edited your message.

When I read this yesterday, I don't remember seeing as much typing, and now I'm looking again and see it has a 'last edit'.

Just wanted to clarify in case my response seemed as if I was asking the same question over.

I may buy a few PIC chips to see if I can program them the way you're suggesting. I need to order some components, a new iron, and replacement pins for the soldering iron connector (one of the heater wires broke off the pin from moving around the PCB).

Yes, from the timestamps, I was still working on the messages above.  I tend to be a little 'trigger happy' with the [Post] button. 

Trying to clone the PIC is worth it - it may resolve any issues due to damaged I/Os other than the ICSP pins (programming pins), and if it behaves the same, at least you then know you've got a spare for future use.  Sorry to hear about the broken heater pin.

FYI: I generally 'tag' my edits at the end of the post with:

Edit: <reason goes here>

if I've made a technical or mathematical mistake I am correcting, and whenever possible, preserve the mistake but use strikeout and italics to make the correction if I've had any replies.  However I edit freely to fix text typos, spelling or punctuation errors any time I see them without tagging, so if you see a 'last edit' timestamp on one of my posts more than an hour after the post's original timestamp, without an 'Edit:' tag, you can bet there is no substantial change worth rereading the post.

Exception: When composing a long post I often post to save it  and go back and add more content, as I've lost more than a few posts being composed to browser crashes and network issues.  If the 'last edit's within an hour of the original post, please reread as I'm probably still adding content.

I was a denizen of the USENET sci.electronics groups, and on USENET, there are no takebacks - what you post is immutable till the last server in the world archiving it dies of bit-rot.  I *HATE* forum users who edit their posts to pretend they didn't say something they've been called out on. 

[bostonman]

Not a problem at all with editing/updating a post.

The part that concerned me: I started a thread about selecting thermocouple wire including how to mount it to a soldering iron and/or hot plate. After, I re-read your update and saw you addressed mounting the thermcouple.

I became worried that I didn't fully read your message and began another message. In my opinion, that looks rude because it appears if I don't get an answer in one thread, then I'm going to start another. Also, I try to keep the thread on point without deviating too much; else it calls for starting a new thread.

Nothing more annoying than searching for an answer, you come across a several page thread, the person who initiated the question vanishes from the thread (most likely because they solved the issue and didn't bother to update the post), and you're reading about nothing pertaining to the original question. In the end, you wasted time reading the thread.

Sometimes if I start a new thread that may have some connection to another, I will make it a point to note that in my message. Again, so this way people don't think I'm double posting.

Having said all this, tonight I purchased a new PES51 iron. I fully agree that having a backup programmed PIC will be good, however, for now, I want to change one thing at a time until the iron is fixed (and post what I find); and then I'll tweak things.

Most likely I'll solder a socket on the board and stick the old PIC in, solder the wire onto the pin (it keeps breaking off), and try the new iron when it arrives. After I'll tinker with making a new PIC if the iron still doesn't work.

Thankfully I have tools that are used for extracting pins. Tonight I was able to remove the broken pin and believe it's an Amphenol. I started a post about the pin type (https://www.eevblog.com/forum/projects/is-this-a-standard-amp-connector-pin/).

I'll either buy new pins, or carefully remove the old broken wire from this and solder the wire directly to it, however, I'd rather replace all the pins if I can find a replacement.

[bostonman]

The new iron will be delivered tomorrow (unless Amazon changes the delivery date). I also ordered an IC socket kit which I'll install an eight-pin socket so I can install/remove the original PIC need be (unless height will be an issue which I hadn't initially considered).

Hopefully either tomorrow or Friday I'll be able to test the iron and will update on the status for those who will need to repair one in the future.

I have two questions and attached two pictures for reference.

It was stated by Ian.M that I need an understanding of PIC assembly to understand the code in order to not keep referring to the datasheet. I took a snapshot of the HEX screen I see and was wondering if it was easy enough to explain one or two instructions. First state of confusion is the line numbers jump by 10 (i.e. 00000010, 00000020) and not 1 (i.e. 00000001, 00000002,..... 00000010). The other is you stated the PIC takes two HEX bytes (4 ASCII).

If ASCI is eight bits, that means all of line number 00000000 are the two HEX bytes? If so, then how do I read that so I can reference the datasheet?

The other is understanding the op-amp section of the circuit. Let's start with the non-inverting side first. The thermocouple produces 42µV/°C. If they produce a voltage based on temp, then what is the purpose of the 5V pull-up and 536k resistor and/or how do I calculate what should be on pin 3?

As for the inverting section, this is tricky because I get confused when an op-amp feeds back to change the voltage such as (what I believe is) a voltage divider.

Pin 7 is Vcc 5V (this got cut out of the snapshot). I assume 14k and 10ohms is a voltage divider, so 3.57mV and the 15k ohm resistor is a current limit of 238nA (3.57mV / 15k). Pin 2 would have 3.57mV at 238nA (this is using an ideal op-amp of course).

Unless I'm wrong in my previous paragraph, now the confusion of the 464k resistor comes into play. Pin 6 (the output) can be anywhere between 0 and 5V (again, using an ideal op-amp).

How do I calculate the voltage at pin 2? The 100nF capacitor is probably just for filtering, so I've ignored that in this discussion.

I'm thinking I can use KVL to calculate the voltage on pin 2, but then I'd need to perform the math for every voltage between 0 and 5v.

Even though the schematic is cut out, I'm assuming everyone remembers pin 6 goes through a 14k and into the PIC (since we are using an ideal op-amp, then it's safe to say the PIC is seeing the same voltage as the output of the op-amp and the current will be limited by the 14k (therefore Vout at pin 6 / 14k).

[Ian.M]

*NOBODY* in their right minds tries to sight read an IntelHex file.  You can pick one apart by hand if you really have to but its very much last resort if all the tools you have are barfing on it, or if for any reason you cant trust your tools.

In this case you need a tool that understands 8 bit PIC machine code, and the best one for the job is the old Microchip MPLAB 8 IDE.

Download and install MPLAB 8.92.
Run it and from the menu bar, do Configure: Select Device... and select PIC12CE673, then File: Import... <your_hexfile>, then View: Program Memory, and at the bottom of the Program Memory window, select Symbolic.

You will get a disassembly listing of your hex file, showing you addresses, instructions, and operands with known register addresses replaced with their names.

You can also do Configure: Configuration Bits... to view what CONFIG options the CONFIG word in your hex file decodes to.

[Ian.M]

The 5K36 resistor in series with +in is to protect the OPAMP if the heater shorts to the thermocouple.  The 1M 5V pull-up is a failsafe - if the thermocouple is working it has negligible effect on the readout, but if it goes open circuit, it makes sure the PIC senses that as 'very very hot' so the heater will shut off.  It probably has another failsafe in the code - if the temperature doesn't increase fairly soon after turning the heater on, either the thermistor is shorted or the heater's gone open and in either case its likely has code to shut it off.

The pin 2 resistor network sets the gain (by feedback) and offset provided by the OPAMP.  The easiest way to work out what is going on is to calculate the pin 2 (-in) voltage for two possible output voltages, then assume the OPAMP is linear for voltages in-between. The pin 3 (+in) voltage will be very very close to the pin 2 voltage due to the negative feedback driving pin 2 till they match.  If you take outputs of 0V and 5V (which it probably can't actually reach)  you can then plot a graph with input voltage against output voltage.  Check the datasheet for the common mode input range, and the max. output swing, and draw a rectangular box on the graph for the region in which the relationship is valid.

Edit: corrected description of +in resistors

[bostonman]

Wow, that looks much better in MPLAB. I don't understand much, but stuff like MOV makes it clear that these can be looked up on the datasheet to figure out what is going on.

You stated at 0x32E is the C Cooper or whatever. I don't see the actual name in MPLAB (probably because it's HEX or ASCII). Looking at the ASCII table, looks like:

0043 = C
0020 = <space>
0043 = C
006F = o
006F = o

I won't bother typing the rest, but looks like it's going to spell Cooper. Not sure how the ASCII characters being in the opcode tells it to spell a name, but I'm sure it would be explained if I study the datasheet.

You also stated it's 810 of actual code (because there are four empty spaces at the beginning - but goes down to 814) but what about lines 0x334, 0x339, and 0x3FF? Should that be 813 lines of code?

I see what you mean about going crazy looking at the program and trying to interpret it via the datasheet. Without looking at the datasheet, looks like line 1 is a goto statement to line 0x55, but not sure what role the opcode (2855) plays (again, I'm sure the datasheet will explain it).

As for your circuit explanation, that makes a bit of sense. I think you made an error; you stated 536k is a pull-up, but think you meant the 1M.

In any case, I guess a linear assumption is an easy way, but the confusion of calculating actual voltages (based on an ideal op-amp) still remains.

Also, your assumption about the code having some protection to sense if the temperature isn't increasing fairly soon, then it shuts off, makes sense. Maybe this is why it heats the iron and seems to regulate, but doesn't blink the LED. Hopefully soon I'll have my answer when I connect the new iron.

[Ian.M]

I corrected the pullup error. See above.

If you select 'Opcode Hex' at the bottom of the program memory window you can see ASCII strings.  Unfortunately it shows non-printable ASCII as . (control codes) or ?(other) so you still need to look up some characters from the hex.  As the program memory word is only 14 bit, it cant store an ASCII character in the high bits of each word. 

At address 0x32E there's a copyright message: "C Cooper Ind. 08/02/2000 V7.5", with the upper part of each word zeroed, not null terminated.

That's *JUST* a copyright message to people dumping the code - the PIC doesn't and cant access the data bytes of the string as 0x00 in the high bits isn't the RETLW opcode.
 
A simpler way of figuring out the temperature/ADC voltage relationship is to model the circuit in a SPICE program.  Here's a rough model using LTspice and its Level 2 UniversalOpamp model, as it *really* did not like T.I's LMC6061 PSPICE model.

[bostonman]

I'll need to download LTspice, however, I modeled it before and got my answer, but it gave me a fish, it didn't teach me how to fish

[Ian.M]

Well I've been disassembling the hex file and patching the result, and here's a  MPASM assembler source file that builds an identical^* binary.  Its largely symbolic, but many bit positions are still numeric.  However its a start towards understanding the code and possibly porting it to a newer PIC.

Edit:  increasing levels of cleanup:  file replaced by one with many symbol names fixed

* if you import and reexport the original HEX file to 'clean' it to MPLAB 8 format, and when you build the source, patch in the same factory OSCCAL value, and export the result to include all unused program memory