HAKKO (907ESD) and SOLOMON (SL-10/30) soldering iron driver

A place to document your own projects.

Re: HAKKO (907ESD) and SOLOMON (SL-10/30) soldering iron dri

Postby pjkim » Thu May 31, 2012 2:06 pm

Still working out some quirks in my soldering iron driver. I am having an intermittent problem with the firmware becoming corrupted requiring reflashing of the firmware (bootloader remains intact and functional fortunately). I posted this to the Diolan bootloader forum because I thought it might be a bootloader issue. http://dangerousprototypes.com/forum/viewtopic.php?f=56&t=3269&start=45#p41137

Another issue is that on some power-ons, the soldering iron goes into calibration mode. Looking at the code, it looks like this is caused by this bit of code
Code: Select all
    while ((measuredTemperature > TOOHOT) || (measuredTemperature < 0)){
        //Calibration is wrong or no hand piece is attached
        //so start calibration function before we continue
        menu = 7;
        encoder = 1;
        runMenu(); //start calibration procedure
        targetTemperature = 100;
    }

For some reason, the first measuredTemperature is out of range. If I press reset, the driver works correctly. If I press menu through the calibration, but don't save/apply changes, the target temp is 100 and I have to set to the desired temp.

Possibilities for the incorrect measuredTemperature are:
1) Faulty first ADC reading
2) Faulty slope and offset values

Will try hooking up the serial debugging port and try to troubleshoot this. Another small problem is button auto-repeating or the lack thereof-- it takes a lot of button presses to get to the temp I want, especially with the default debounce time. Will try using a rotary encoder to see if it is a better interface or failing that, will try adding auto-repeat, shortening debounce time, reading desired temp from potentiometer through unused NTC port, etc.
pjkim
Newbie
Newbie
 
Posts: 46
Joined: Mon Apr 09, 2012 1:18 pm

Re: HAKKO (907ESD) and SOLOMON (SL-10/30) soldering iron dri

Postby arhi » Thu May 31, 2012 3:09 pm

yup, that is the code that sends the driver into calibration mode on power-on. The idea was that if you read something "wrong" (like too hot or too cold) you assume you have wrong device attached and you start calibration procedure and prevent SID from damaging your iron. If you know what your iron is you can fix that in firmware and remove that piece of code completely.

Now, why this pops up even with normal iron attached
- lose wire
- wrong calibration data
- gremlins :D
but most probably it's the wrong ADC read at powerup, probably ADC need some time to settle so possibly some delay should be introduced right before this while(). IIRC there is a delay there .. you might just wanna make it longer (3 or 4 times longer) to allow ADC to settle.

As for autorepeat on buttons, yes I assume it's pain in the butt :( it's because the interface was made to use rotary encoder and when you rotate the darn thing it clicks them on and off ... so when using buttons... It should be fairly easy to add some autorepeat functionality on buttons, I just can't do it today, maybe tomorrow.. or you can try yourself, you need to do it inside timer2 interrupt (every 2ms) and not in the INT1/INT2 where buttons are handled now. It should be very simple.
User avatar
arhi
Hero Member
Hero Member
 
Posts: 2160
Joined: Thu Jun 24, 2010 11:41 am
Location: Belgrade, Serbia

Re: HAKKO (907ESD) and SOLOMON (SL-10/30) soldering iron dri

Postby pjkim » Thu May 31, 2012 3:46 pm

Regarding giving the ADC time to settle, the first read is after the "SID $Rev: 34 $\nelco.crsndoo.com" splash screen so I can't imagine the PIC needing any more time to settle. Do you mean during the ADC acquisition? I see that BusyADC() is polled until the conversion is ready so no more delay is required there. Perhaps the PTC amplifier needs even more time to settle? I actually have the caps soldered in place for the PTC amp. I didn't have problems with oscillations and I only found out later that you removed yours. Perhaps I should try looking at the power-on characteristics of the PTC amplifier with the caps in place-- maybe they do oscillate, maybe they need to go. Have an oscilloscope, will hook up and have a look.

I will give the rotary encoder a shot. One thing I didn't understand was the flag for double detent. Is that a flag for a certain type of encoder? Number of transitions per detent?

If no success with the encoder, will give the auto-repeat programming a shot-- the biggest hurdle is grokking PIC registers/interrupts/configs.
pjkim
Newbie
Newbie
 
Posts: 46
Joined: Mon Apr 09, 2012 1:18 pm

Re: HAKKO (907ESD) and SOLOMON (SL-10/30) soldering iron dri

Postby arhi » Thu May 31, 2012 4:01 pm

It's possible that PTC amp is oscillating, also it's possible that op needs time to settle, you said you used some other op and not the mcp one I put there or I mixed it up?

as for the detent, some encoders don't have any detent's so those can work any way you set the flag, some have single transition between detents and some have double transition. Double transition one are designed to use interrupt on only one pin so depending on what type of encoder you have you set the flag or not.

for autorepeat, you do not need to play with pic guts, everything is there, just remove the code that runs on interrupt for button press and implement code in the tmr2 interrupt (set flag for old state, read new state, measure time passed, increase or decrease by N where N increases over time ..)
User avatar
arhi
Hero Member
Hero Member
 
Posts: 2160
Joined: Thu Jun 24, 2010 11:41 am
Location: Belgrade, Serbia

Re: HAKKO (907ESD) and SOLOMON (SL-10/30) soldering iron dri

Postby pjkim » Fri Jun 01, 2012 11:57 am

I used a MCP619 for the low voltage op amp. I checked the filtering on the PTC amp using an oscilloscope and it looks like a textbook example of a RC step response, no oscillation whatsoever. I didn't measure tau, but guesstimation is about 0.2s. The temp pin is stable by the time the splash screen is over. Calculating the values for the Sallen/Key filter, f should be 19Hz and the q value is 0.03 so looks like it is in the right ballpark (please excuse use of north american idioms).

Values used for above calculation are R = 15k, C = 10uF, m = 0.67, n = 1/212 (according to the conventions used on the wikipedia page http://en.wikipedia.org/wiki/Sallen%E2% ... y_topology). You had mentioned oscillations in your PTC filter due to incorrect calculation of the values. They look and work pretty well for me.

Will try hooking up the rotary encoder this weekend. If I don't like it, I will try implementing auto-repeat.
pjkim
Newbie
Newbie
 
Posts: 46
Joined: Mon Apr 09, 2012 1:18 pm

Re: HAKKO (907ESD) and SOLOMON (SL-10/30) soldering iron dri

Postby arhi » Fri Jun 01, 2012 12:20 pm

Well I calculated the values to get that but I got oscillations - no clue why. Might be pcb error (I got 12 pcb's from itead, almost all had some mistakes on them :( and they supposed to be 100% etested) on mine pcb's who knows..
User avatar
arhi
Hero Member
Hero Member
 
Posts: 2160
Joined: Thu Jun 24, 2010 11:41 am
Location: Belgrade, Serbia

Re: HAKKO (907ESD) and SOLOMON (SL-10/30) soldering iron dri

Postby arhi » Fri Jun 01, 2012 12:21 pm

pjkim wrote:The temp pin is stable by the time the splash screen is over.


Did you measured stable value on the pin when it jumped to calibration routine?
User avatar
arhi
Hero Member
Hero Member
 
Posts: 2160
Joined: Thu Jun 24, 2010 11:41 am
Location: Belgrade, Serbia

Re: HAKKO (907ESD) and SOLOMON (SL-10/30) soldering iron dri

Postby pjkim » Fri Jun 01, 2012 12:35 pm

Arhi wrote:Did you measured stable value on the pin when it jumped to calibration routine?

No, did not. I am going to move the UART initiation up in the startup sequence and output the first ADC value and calculated temperature to see what is throwing this off. Will keep you posted.

I have checked the 5V in the past, not recently, and it was very clean-- difficult to see any ripple at all.
pjkim
Newbie
Newbie
 
Posts: 46
Joined: Mon Apr 09, 2012 1:18 pm

Re: HAKKO (907ESD) and SOLOMON (SL-10/30) soldering iron dri

Postby arhi » Sun Jun 03, 2012 3:40 pm

yes with dual inductor and lot of caps 5V should be very nice. On the other hand if you use low quality inductors you can have problems (for e.g. on one board I have 4.2V and found out that 1uH inductor had some huge resistance, so had to replace it)

Anyhow, it would be cool to see both on the scope and on the usart what the hack is going on on the ADC pin when it jumps into calibration routine as it means that it readed wrong value. This "messed up firmware and eeprom" values are worrying me. I never seen this, not on SID nor on any other pic project I worked on... had it few times on atmel but it was a compiler bug and I had a pointer that was messing up the code, anyhow, SID code is super simple so this could not be possible, also I'm using it for a while and never noticed that, and few other ppl are using it without problem .. maybe it has something to do with diolan bootloader ?! donno ..
User avatar
arhi
Hero Member
Hero Member
 
Posts: 2160
Joined: Thu Jun 24, 2010 11:41 am
Location: Belgrade, Serbia

Re: HAKKO (907ESD) and SOLOMON (SL-10/30) soldering iron dri

Postby pjkim » Mon Jun 04, 2012 3:34 am

So I think I have fixed one of my problems, the one causing the SID to go into the calibration menu on startup right after the splash screen. I put in a few extra debug outputs and listened on the serial port. I suspected that the initial ADC values were incorrect so I printed the slope, offset and rawADC prior to the line in the program checking for a valid measuredTemperature value. I also printed a full set of time, set temp, measured temp, etc. I put in another call to readTemperature() to get the rawADC value (actually rawADC/8.0).

Here is what a normal start looked like.
Code: Select all
Prerun values:
slope, offset, rawADC 0.7500,-207.0000,325.2500,
2.2300,100.0000,36.5625,36.7741,3.5000,1.8750,3.2500,0.0000,0.0000,0.0000,0  <-- my debug
2.4660,100.0000,36.2812,38.0645,3.5000,1.8750,3.2500,223.0181,100.0000,-117.-9140,100  <-- normal loop from here
2.7040,100.0000,36.8906,38.7096,3.5000,1.8750,3.2500,223.0181,100.0000,-117.-9140,100
2.9440,100.0000,37.7109,38.7096,3.5000,1.8750,3.2500,223.0181,100.0000,-117.-9140,100


Here is what a bad start looks like
Code: Select all
Prerun values:
slope, offset, rawADC 0.7500,-207.0000,322.0000, *** rawADC value is read after splash screen
2.2300,100.0000,-71.-625,37.7419,3.5000,1.8750,3.2500,0.0000,0.0000,0.0000,0  <-- my debug. Although this line comes after, the temp values here were read before the splash screen.
***This is the end. It goes straight to the calibration menu because the set temp is -71, ie out of range.


Looking at the set temp of -71, the rawTemp must be about 181 (= (-71 +207)/0.75). This is set in loadDefaults(). But my reading of the rawADC is 322 which converts to 34.5 which is in range. So the first reading of the temperature is very different from the second reading. I discarded the first reading by inserting this line
Code: Select all
measuredTemperature = adc2temp(readTemperature(1));


before the line checking for temperature out of range and the problem appears to have been resolved. I think what is happening is that loadDefaults() is called very early, before the splash screen is put up. After the splash screen, the PTC amp has settled so the second reading is accurate-- remember I have the caps in for the Sallen/Key filter with a rise time of 480 ms (I measured). You are not having a problem because your PTC amplifier settles much faster without the caps. In my situation, there is a race condition between the first read of the temperature and the PTC amplifier settling. Things make a lot of sense now.

I think the easiest fix is to move the call to loadDefaults() to after the splash screen. By then the PTC amp should have stabilized. Also, this fix will work regardless of whether the filtering caps were installed or not.

I also haven't had the firmware corruption in a while, although you never know with an intermittent problem. Keeping my fingers crossed. Also, the buttons are starting to grow on me, now that I don't have to change the InitTemp setting so often. Trying to motivate myself to write the autorepeat but also eager to start another project I've been thinking about-- a hot-wire driver using a buck converter.
pjkim
Newbie
Newbie
 
Posts: 46
Joined: Mon Apr 09, 2012 1:18 pm

Re: HAKKO (907ESD) and SOLOMON (SL-10/30) soldering iron dri

Postby arhi » Mon Jun 04, 2012 4:40 am

I said I suspect the op-amp/adc are not "ready" and that adding some delay might help :D. The main problem is readtemp at the end of the load defaults ...

I moved load defaults down so it should be ok now. (committed already)
User avatar
arhi
Hero Member
Hero Member
 
Posts: 2160
Joined: Thu Jun 24, 2010 11:41 am
Location: Belgrade, Serbia

Re: HAKKO (907ESD) and SOLOMON (SL-10/30) soldering iron dri

Postby arhi » Mon Jun 04, 2012 4:43 am

btw any idea what changed before you stopped having corruption problems? Maybe you removed bootloader ? or something else?

as for buttons, yes, when you get it up and running you do not have a need to play with buttons too much so autorepeat is not required
User avatar
arhi
Hero Member
Hero Member
 
Posts: 2160
Joined: Thu Jun 24, 2010 11:41 am
Location: Belgrade, Serbia

Re: HAKKO (907ESD) and SOLOMON (SL-10/30) soldering iron dri

Postby pjkim » Mon Jun 04, 2012 9:51 am

I am always reluctant to declare victory on a problem when I don't have any idea what caused it in the first place or what made it go away or if it has gone away at all. I am still using the bootloader, the 5V supply is clean, clean, clean. I have no idea. If it happens again, will let you know.
pjkim
Newbie
Newbie
 
Posts: 46
Joined: Mon Apr 09, 2012 1:18 pm

Re: HAKKO (907ESD) and SOLOMON (SL-10/30) soldering iron dri

Postby arhi » Mon Jun 04, 2012 9:58 am

same here - I never consider problem solved unless I know how it is solved. I hoped you removed bootloader and problem went away (that would show problem in bootloader), but since you changed nothing - who knows, it can be any number of things (I still suspect bootloader).

Glad you have it up and running :) keep us posted
User avatar
arhi
Hero Member
Hero Member
 
Posts: 2160
Joined: Thu Jun 24, 2010 11:41 am
Location: Belgrade, Serbia

Re: HAKKO (907ESD) and SOLOMON (SL-10/30) soldering iron dri

Postby pjkim » Thu Jun 14, 2012 1:01 am

I changed a few things in the code to improve the debounce and add autorepeat. The debounce uses a modification of Kenneth Kuhn’s debounce method (http://hackaday.com/2010/11/09/debounce ... e-them-all). The improvement is that the code will register button presses as fast as you can press them. The autorepeat has a delay of 0.3s and a repeat rate of 6.25Hz which feels comfortable. You can change these by changing AUTOREPEAT_DELAY and AUTOREPEAT_PERIOD in hardware.h

I have tried to play nice with the USE_ENCODER flag. It compiles correctly with the flag not set, ie for buttons. I don't know that it behaves correctly with an encoder-- I don't have one set up to test. The buttons have grown on me with the faster debounce and the addition of autorepeat. I changed things so that when you use buttons, INT0, INT1, and INT2 are turned off. Everything runs off the 500Hz timer2 interrupt. I left the INT1 and INT2 routines in place (after removing the button specific code) but these should never get called because the interrupts have been disabled. When the USE_ENCODER flag is set, INT0 through INT2 are left on.

It took an frustratingly long time to debug until I realized/remembered that the buttons go low upon button press. (insert frustrated, smiling emoticon wearing glasses here)

I have had no further problems with firmware corruption. I wonder whether it may be related to runaway code when I power down. I have noticed that when I turn the switch off, I can sometimes see the splash screen come on for an instant before the power goes away completely. Perhaps during that instant, sometimes the bootloader passes execution to the firmware and hence the splash screen, and other times goes rogue and overwrites firmware. Just a theory.
Attachments
debounce_autorepeat.zip
main.c and hardware.c
(7.77 KiB) Downloaded 483 times
pjkim
Newbie
Newbie
 
Posts: 46
Joined: Mon Apr 09, 2012 1:18 pm

PreviousNext

Return to Project logs