Weller Soldering Iron WES51

[bostonman]

oh wow.... looks like you're really diving into this.

I think dissecting it to make the code readable to humans would be cool, but it really depends on how much time you care to devote to this. Most likely not many people care, but, for the sake of troubleshooting, it could come in handy.

[Ian.M]

It looks like the I2C EEPROM routines are based on an older version of the FL67XINC.ASM code as described in section 6.0 of the datasheet.
The commented sourcecode can be found in:
   https://ww1.microchip.com/downloads/en/DeviceDoc/ce67xv11.zip
which I got from the PIC's product page.

I've updated disasm.asm with the I2C routine labels and named variables and done some cleanup on warnings.  It still builds an identical binary.

[Ian.M]

So I've managed to pull the I2C EEPROM library out of the main source file by patching FL67XINC.ASM slightly.  This is great progress because the FL67XINC.ASM library is well commented and has a well-defined interface, so we no longer have to consider how to save/restore data to/from EEPROM, and can concentrate on figuring out *WHAT* is saved in the EEPROM and how (and when) it is used.   It also brings porting it to a newer PIC with EEPROM on the same die within reach by writing an  interface compatible 'wrapper' for that PIC's native EEPROM peripheral. 

I've also named pins etc. to slightly clean up the main program.   As always, it still builds an identical binary.

ToDo: 

• Figure out and comment the ADC routines for reading bit temperature and setpoint knob.
• Investigate the TRIAC firing code

+ a lot more work that will no doubt appear as we dive into it!

[bostonman]

I'll check out the files after.

With the exception of replacing the 33uF on the half wave rectifier circuit with a 100uF 25v (it's all I had and I know it's underrated - it's only temporary), and soldering a heater wire to the pin, the station is in its original configuration.

I connected the new iron to it and unfortunately the LED didn't blink. The iron got hot enough to melt solder and I turned down the knob so the LED should have turned off while it was cooling to the new temp, but it didn't blink when ready nor turn off while cooling.

Unfortunately I can't get an accurate temperature reading to determine if it's controlling, but, previous measurements using the junk tip indicated it controls.

Odd that the PIC will turn on the green LED, turn on the red LED (when I 'lock' it using a magnet), tell the TRIAC to turn on the heater, possibly control the temperature at the set point, but won't blink the LED.

At this point I guess the solution is to buy blank PICs and program them. Looks like I must have touched two pins while taking measurements and caused an output to get damaged (my only guess).

I'm a bit upset at myself for diving too deep into this and not replacing the iron. It would have saved me from damaging the PIC, however, the upside is that I was able to provide the code to everyone.

Ian.M,, although you are still in the process of doing a great job diving into the code, do you see anything that would indicate it's corrupt, or can I go ahead and order new PICs?

Also, from the looks of the part number stamped on my chip, it's a 4MHz. The part number is:

12CE673
P04 <space> 35B
0304

The P seems to be in the wrong place from what I can tell on the datasheet.

[Ian.M]

I've validated approx. 20% of the code so far as either identical to the Microchip EEPROM library code (I suspect an older version due to two lines not present in the disassembly and one wider bitmask), or as making sense in context.  It is therefore 100% certain that the PICs internal ICSP support silicon is functional at least for readout, and that your programmer can read the PIC.  However EPROM is not immune to 'bitrot' even though it usually takes several decades for it to degrade to the point one or a few bits start to be misread so there is still a vanishingly small possibility the code *may* be corrupt due to a single location bit flip.  Your odds of winning a major lottery by finding a ticket on the street are higher!

The PIC has to be a 4MHz one, as the only internal oscillator option is 4MHz, and unless forced to by supply chain issues I can't see Weller paying the premium for the 10MHz part then running it at 4MHz.  Don't worry about the speed grade of the replacement, as all will do the job.

Edit: 164 (of 810) instructions checked and either commented for algorithm or determined to be fully commented library code.  So far, I've groked the line frequency check immediately after powerup:

Code: [Select]

; Find period of AC line (secondary drives LINESYNC pin (GP2/INT)
; with line frequency near-squarewave).
;
find_period
        movlw           0x02 ; set count for two passes of inner loop       
        movwf           count_m26

period_iloop ; do{
        clrf            INTCON ; disable interrupts, clear INTF flag

waitfalling0
        clrwdt
        btfss           INTCON, INTF
        goto            waitfalling0
        bcf             INTCON, INTF
        clrf            TMR0

waitfalling1
        clrwdt                     
        btfss           INTCON, INTF
        goto            waitfalling1
        bcf             INTCON, INTF ; ome mains period later
        movf            TMR0, W
        decf            count_m26, F ;}
        btfsc           STATUS, Z    ;} while (-- count_m26);
        goto            skip_wf    ;}

        movwf           period_m25
        goto            period_iloop

skip_wf
        xorwf           period_m25, F   ;
        btfss           STATUS, Z   ;  if not the same, repeat find_period
        goto            find_period    ;

        movwf           period_m25 ; got the mains period in units of 256us

; Compare with various periods to reject line frequencies outside the
; range 48.83 Hz - 62 Hz and split between 50 Hz and 60 Hz (at 54.25 Hz).
;
        movlw           0x3f ; if(period < 16.128 ms) goto find_period
        subwf           period_m25, W ;
        btfss           STATUS, C ;
        goto            find_period ;
;
        movlw           0x48 ; if(period < 18.432 ms) goto do_60Hz
        subwf           period_m25, W ;
        btfss           STATUS, C ;
        goto            do_60Hz ;
;
        movlw           0x50 ; if(period < 20.480 ms) goto do_50Hz
        subwf           period_m25, W ;
        btfss           STATUS, C ;
        goto            do_50Hz   ;
;
        goto            find_period ; else goto find_period

; Set two values, one in mem3_f & mem_40, other in mem_34, mem_44 & mem_33
; to consts by line freqency.
do_60Hz
        movlw           0x78
        movwf           mem_3f
        movwf           mem_40
        movlw           0x0c
        goto            skip_lf
;
do_50Hz
        movlw           0x64
        movwf           mem_3f
        movwf           mem_40
        movlw           0x0a
;
skip_lf
        movwf           mem_34
        movwf           mem_44
        movwf           mem_33


[bostonman]

do you see anything that would indicate it's corrupt, or can I go ahead and order new PICs?

I realized after typing this that it sounds as if I'm worried about the cost of a new PIC. They are only $3.xx and I'm not worried at all, however, because I removed and reinstalled a few chip components (resistors and a cap) because I thought the op-amp section wasn't measuring correctly, I'd like to replace these. Also, I need to replace the socket pins due to the wire breaking, and in the process with TE to figure out which part number to order.

My plan is to overhaul the iron (one I get it to work correctly) with new socket pins, components that didn't see extreme heat due to unsoldering and soldering, order a few PICs, and have spare parts too of the one off stuff (poteniometer, regulator, etc...) just in case of future repairs.

Edit: I don't know what Weller was thinking, I forgot to add that I physically measured the chip resistors and capacitors, they are: 0.06" x 0.125 with a height of approximately 0.02"; the capacitors are the same, but seem to have a height of approximately 0.03".

I confirmed the chip resistors are bigger than the 0802 I have in my stock when compared them along side each other. Obviously trying to get an accurate measurement with solder on them isn't easy, but seems those are the dimensions.

From what I can tell, these are uncommon and most likely will be difficult to order.

[bostonman]

I haven’t gone cold, I just haven’t ordered components, however, I did last night and will plan to program a new PIC when they arrive.

[bostonman]

I finally got my components order.

Ian.M, per your steps, I've read the blank PIC (and 'verified' it's blank with a 'blank check'). From what I can tell, address 0x3FF has an OPCODE of 349C and RETLW 0x9C (whatever this means) - see attached Blank1.hex file.

Will different blank PICs have different values?

From what I've understood, when I attempt to write the HEX file that I saved from the original PIC, I need to enter a starting address, and enter 349C or 0x9C? Once I've done that, then I just write the code, verify it, and I should have a duplicate PIC (that hopefully now functions by blinking the LED)?

I'll be honest, I don't know what all this means, so I'm only going by steps, however, I expect I'll learn more as I go along.

[Ian.M]

Yes, different blank PICs (of this type) most probably have different value at 0x3FF.  If they came from the same wafer they probably have the same value, otherwise its random chance whether they match.  The RETLW opcode (34h) always stays the same, but the data byte varies.

All official Microchip programmers and fully compatible ones preserve the factory OSCAL RETLW (or MOVLW) for PICs that have it, by excluding it from programming, and on FLASH PICs, reading it before any other programmer operation, and writing it back after any Erase.  Unfortunately your third party programmer is generic and I suspect doesn't have the special OSCAL handling, so you must preserve it manually, by ensuring that the contents of the buffer for that location match the contents of the new chip, *before* actually programming.   

[bostonman]

A possibility exists that I'm down one PIC with two left to go.

I expected to see a popup menu when I pressed 'PROGRAM', and think it just wrote the empty buffer back onto the PIC because it began programming.

In any case, after this mistake. I figured out that I need to  'open' a file and then I get the following popup window (see attached).

For file type, this seems obvious, I select Intel. For 'File Mode' I assume leaving it as normal. The other options (to list a few) are: even (1st of 2), odd (2nd of 2), 1st bye of 4, etc...

The rest I'm uncertain about. Is 'Buffer Address' where the 349C or 0x9C would be entered (I'm uncertain which one I'd use, but think you answered it to be 9C). Also, from what you said, if I use another PIC, these addresses may be different.

[Ian.M]

Blank1.zip above appears to contain an image of an unprogrammed PIC with factory OSCCAL: RETLW 0x9c
If that is after your misadventure writing the blank buffer, I'd bet that PIC is still usable.

Personally, as the programmer software doesn't offer second chances, I'd read the blank PIC to get the OSCCAL data and note it down, import the original WES51 hex file in MPLAB, patch the OSCCAL RETLW data at the end of the program memory, export the hex file (with a new name) for the full range of the program memory + the config, then check it imports back correctly after clearing the program memory, so I don't have to mess around in the programmer software.   Do a dummy run with no PIC inserted and see if that workflow makes sense then try again with the PIC that you think you wrote the empty buffer to.  At best it will succeed, at worst fail on verify.   Finally, when you are certain its set up correctly to write the whole program memory + the CONFIG, repeat the whole process of getting the OSCAL data, patching and writing, with a fresh blank PIC.

[bostonman]

The blank1.hex file above is a read right out of the static bag. I hit 'program' afterwards, but it still checks as 'blank'.

I'd read the blank PIC to get the OSCCAL data and note it down, import the original WES51 hex file in MPLAB, patch the OSCCAL RETLW data at the end of the program memory, export the hex file (with a new name) for the full range of the program memory + the config, then check it imports back correctly after clearing the program memory

As mentioned above, I think the OSCCAL data was read (at 0x3FF) and step one is complete (?). As for patching, I'm uncertain about these steps. Is just entering a starting address in one of the fields shown in the screen shot above too risky?

[Ian.M]

Buffer address and File address in the load dialog are nothing to do with patching the hex file. Instead they are for offsetting the hex file.   Suppose you had an old 8 bit CPU that started execution in high memory (lets suppose the reset vector is 0xFFFE), and you wanted to program 8KB of ROM for it into two 2732 4Kx8 EPROMS.
Your ROM code is assembled starting at 0xF000 (because it isn't relocatable) but the buffer for a 2732 only goes up to 0x7FF.   Therefore for the first EROM you'd use a file address (offset) of F000 (hex) and it would load that 4K buffer size 'window' from the file.   To program the second EPROM, you'd use file address F800 to load the upper half of the assembled ROM code.

Similarly, 'Buffer address' can be used to offset code in the resulting EPROM, useful if you've got hardware paging switching the higher address lines to let one large EPROM chip hold several 'ROMs'.

The 'file mode' option is for splitting a file between two EPROMs connected to the upper and lower bytes of the data bus for a 16 bit word CPU or four for a 32 bit word CPU.   

Both are irrelevant for 8 bit PICs, so leave file and buffer address offset set at zero and file mode at normal.  Filetype must be set to IntelHEX.

*IF* you were going to patch memory in your programmer software (not recommended), you'd do so in the buffer after successfully loading the buffer.  Beware: buffer addresses do not match PIC program memory addresses as the buffer is bytes, but the PIC has 14 bit instruction words, as discussed previously.

[bostonman]

That makes much more sense and a bit of PIC knowledge.

I spent time trying to look for OSCCAL and RETLW last night in MPLAB, but basically spun my wheels (to use a corporate term). Is this easy and I overlooked something or not easy for a beginner?

[Ian.M]

MPLAB and/or MPASM help wont have anything about OSCCAL, as the MPLAB simulator doesn't support it (simulator clock is fixed 'frequency' set in a dialog), and the details of using it vary from device to device.  Consult your PIC's datasheet for details.

See section '4.2.2.7 OSCCAL REGISTER' for details of the register itself, and section '9.2.5 INTERNAL 4 MHz RC OSCILLATOR' for details of using the factory calibration data with it.  You'll find details of the CALL and RETLW instructions in section'10.2 Instruction Descriptions'.

[bostonman]

I have to be honest, the more discussion about this, the more confused I get.

Initially I thought having the PIC program and just entering a starting address to burn onto a new PIC was enough, and something somewhat simple.

At this point, I'm baffled on how to go about this. Maybe it's not having any experience with PICs, but I've looked at the datasheet, and did some research, but not sure which steps need to be taken.

All official Microchip programmers and fully compatible ones preserve the factory OSCAL RETLW (or MOVLW) for PICs that have it

Would I be better off just buying a programmer off Amazon per your statement or can you help provide the steps to make this work with my existing programmer?

[Ian.M]

All PIC12/16/18C... PICs (with the exception of PIC16C83/84) are EPROM PICs.  All PICs with 'F' or 'LF' in the middle of the part number are FLASH PICs.  Unfortunately none of the current Microchip development programmers (or their clones on Amazon etc.) support EPROM program memory PICs (which can draw up to 100mA Vpp current during programming), they are all for FLASH program memory PICs for which Vpp is only a bias voltage to enable the internal programming supply charge pump.   I also cannot with a clear conscience  recommend dropping the hundred bucks or so a second hand Picstart Plus (the last EPROM PIC capable development programmer) would cost you as it is unsupported in MPLAB X, has limited support for FLASH PICs and may need you to preserve a legacy PC to use it, and there is no reason to ever use EPROM PICs except when repairing legacy devices.

I've got a workflow for you that should preserve the OSCCAL factory calibration RETLW without you needing to manually patch it.

• Insert blank PIC and read it into the buffer
• Load the attached HEX file (from which I stripped the OSCCAL RETW using MPLAB Export), with the 'Buffer clear on data load' checkbox in the 'File Type' dialog unchecked (to preserve the OSCCAL RETLW just read from the PIC)
• Write the buffer to the PIC and Verify

Location of 'Buffer clear' checkbox:

[bostonman]

I was unaware the programmers were that expensive; maybe I looked at knock offs before because I swear they were cheaper. As you pointed out, buying one would be a waste because I'd probably never use it again (and why I've pushed to use my existing).

Either way, I appreciate you removing the stuff you mentioned and uploading a new HEX file. I followed your steps, and, just to reiterate, I'll list them:

Inserted the PIC
Read the PIC (although I'm uncertain why I needed to read a 'blank' PIC)
Loaded the HEX file you provided
Unchecked the 'Buffer Clear On Data Load'
Clicked 'Program'
Clicked 'Verify' (which verified fine).

A few added bonuses: After programming it, I checked to see if was blank (i.e. 'Blank Check') which returned an error (I assume this was informing me it wasn't blank).

I also 'Read' the newly programmed PIC and attached the file (I'm not editing the extension and keeping it as it was saved just in case you need to do something other than just add an extension).

Also, I loaded the original HEX file from the original PIC I 'Read', clicked 'Verify', and it verified good.

I assume since it verified good when comparing it to the original HEX file from the original PIC, this means it wrote it to which ever location it needed to and the code hasn't been edited meaning you didn't accidentally change any of the functions.

Now all I need to do is install it and keep my fingers crossed, correct?

[Ian.M]

You needed to read the new 'blank' PIC to get its factory OSCCAL calibration into the buffer, in case the programmer software isn't smart enough to lock out that location for writing.  Step 2 then merged it with the 'deOSCCALed' hex file.

I can confirm the *ONLY* difference between the read-back and your original hex file is the factory OSCCAL calibration data byte, which is as it should be.

[bostonman]

I can confirm the *ONLY* difference between the read-back and your original hex file is the factory OSCCAL calibration data byte, which is as it should be.

If I'm reading this correctly, you mean a difference exits, but the OSCCAL should be different?

You needed to read the new 'blank' PIC to get its factory OSCCAL calibration into the buffer, in case the programmer software isn't smart enough to lock out that location for writing.  Step 2 then merged it with the 'deOSCCALed' hex file.

This makes sense. I'm only guessing, but would imagine the buffer gets overwritten when a new file is loaded (or read), however, I didn't take any chances. When I executed your steps, I followed them as indicated, but, in the case of reading the newly burnt HEX file, I closed the programming software, opened it again, and then read the burnt HEX file off the new PIC.

I'm uncertain if I'll have time today to remove the old (broken?) PIC and install this, but I should either tomorrow or this weekend. Obviously I'll update this thread when I do.

[Ian.M]

Yep.  The factory OSCAL calibration RETLW data byte difference is expected, intended and desirable.

When you read a device the whole buffer is always overwritten with the device memory contents.  When you load a hex file, what happens depends on the 'File Type' dialog settings + the address ranges of the data present in the hex file.  If 'Buffer Clear On Data Load' is checked, then all buffer addresses not 'covered' by the hex file get cleared to the fill value in the dialog (default FFh), but if its unchecked they keep their old contents, allowing you to merge multiple hex files (+ existing data) in the buffer.

[tooki]

Edit: I don't know what Weller was thinking, I forgot to add that I physically measured the chip resistors and capacitors, they are: 0.06" x 0.125 with a height of approximately 0.02"; the capacitors are the same, but seem to have a height of approximately 0.03".

I confirmed the chip resistors are bigger than the 0802 I have in my stock when compared them along side each other. Obviously trying to get an accurate measurement with solder on them isn't easy, but seems those are the dimensions.

From what I can tell, these are uncommon and most likely will be difficult to order.

What are you talking about? 1206 is a standard size. Commonly used nowadays for power resistors, larger caps, and for SMD beginners. (For non-power parts, 0603 and 0402 are the most common these days. 0805 is arguably rarer still, since it’s only a bit bigger than 0603.)

[bostonman]

Maybe I overly worded my statement.

All the stuff I've come across at jobs have been 0805 and some home projects 0603 (or maybe 0402), I've never come across 1206.

From my brief experience and my opinion, the PCB is laid out like an amateur did it. The components are clumped together in certain areas, and then an extensive amount of space between the circuits. Etches go under components due to trying to clump circuits. It's a double sided board, yet, they stuck things like capacitors between the backside of the front panel and the PCB forcing them to use underrated voltage capacitors.

Having said all this, after discovering the components are 1206 (I figured this out after I researched the dimensions I measured and after posting that statement in this thread), I feel the component size is overkill for the lower power circuits. They could have got away with 0805 - assuming these are cheaper than 1206.

Since they were trying to save room for whatever reason on a board that's larger than needed, why waste time using 1206 size components?

Also, they used a half-wave rectifier (not that noise is an issue), and used a 33uF 35V capacitor. Due to height limitations, I can't increase the capacitor and voltage.

In any case, yes, maybe my statement was a bit too hasty, but much of this PCB doesn't make sense to me and probably overtook some of my thoughts.

[Ian.M]

They needed to keep TRIAC MT1 at chassis ground due to their choice of drive circuit, and that meant they couldn't use full wave rectification for the controller.  Whether or not the bulk decoupling cap is adequate depends on how much ripple is on it, which depends on the controller's load current.  You could always fit 0.1uF ceramic to its pads and run wires to a larger higher voltage electrolytic mounted off-board.

[tooki]

Maybe I overly worded my statement.

All the stuff I've come across at jobs have been 0805 and some home projects 0603 (or maybe 0402), I've never come across 1206.

…

Having said all this, after discovering the components are 1206 (I figured this out after I researched the dimensions I measured and after posting that statement in this thread), I feel the component size is overkill for the lower power circuits. They could have got away with 0805 - assuming these are cheaper than 1206.

Since they were trying to save room for whatever reason on a board that's larger than needed, why waste time using 1206 size components?

If you’re as a much of a novice as you say you are, then what makes you think you think you’re in a position to judge whether they were the right choice, and whether the PCB layout is good or not? (Why don’t you post some pics of the boards? You have me curious.)

Many factors come into play with component choice: power rating, component characteristics (especially with caps*), assembly method, etc.

For example, if you want to glue and wave solder SMD parts, larger parts are easier to glue, and less likely to have shorts. Remember also that this station is very old. It’s eminently possible that at the time, smaller components cost more (even though they are cheaper nowadays). Larger components can also be pick-and-placed more quickly (because less precision is required), or with older equipment, freeing up modern machines for other jobs. (That’s why nowadays, you’ll generally pay more to have components smaller than 0402 placed.)

Heck, it could be as simple as “we stocked up on these 1206s and need to use them up before they tarnish”. Or maybe it was a board originally designed even longer ago for a predecessor model.


* with ceramic capacitors, the larger you can make it for a given capacitance, a) the higher the voltage rating can be, and more importantly b) the less capacitance loss there is with DC bias. (The high-capacitance dielectrics used for small, high-capacitance caps lose capacitance with voltage, and it can be very significant. Like 20-80% loss in capacitance. For example, a “10V” 0402 cap might lose 10% of its capacitance at 3V, but 60% at 9V! For power supply filtering, this can be very significant. And it causes distortion when used for AC signal applications.) This is effect is substantially reduced in physically larger caps.