I've tried both NoOpt (-O0) and best possible optimization with the free compiler (-O1 for v.133), without bootloader. So in my opinion using any newer XC32 is better, if you don't have the pro version. The newer version seem to permit a lot more optimizations, yes.
maybe v1.33 really only works with -Os (which I cannot do, free version, I do not know. I can only tell you that if I compile with v1.33, regardless of the settings available to me, I get the behaviour I described earlier.
Should you guys need help further developing the unisolder and need help, feel free to hit me up, I'd be interested, if I am of any help to you.
so, I just tried compiling with XC32 v2.50, of course after installing the legacy plib. Without any optimisation the firmware compiles, but does not run properly on the microcontroller. The iron's temperature is not stuck at room temperature, but very erratic, in my case basically useless, because the regulation does not work properly as far as I can see. With all optimisations (the free version permits) enabled, the firmware compiles and runs on the microcontroller without any problem. The same code compiled with v1.33 (free version, regardless of the settings) does not work on the microcontroller and shows the symptoms I had earlier.
So, I guess my main problem was the compiler version, for me v1.33 does not work at all. Maybe the microcontroller really was faulty, too, but I am not that sure anymore...
@afedorov: thanks for the nice idea regarding the original .hex file. On the old microcontroller I replaced that did not work. But, interestingly, on the new one the original hex file does work. so, thank you for that idea. The temperature does now show something other than room temperature, something that might actually resemble the iron's tip's temperature, but I haven't measured with a thermometer yet.
One more problem remains. From my understanding, the original -Os optimization level was necessary to fit the firmware into the microctonrollers memory. The pic used in the schematics (PIC32MX564F128H) does have enough memory to fit the firmware even without -Os. So, I got the free version of XC32 v1.33, and compiling with -O1 works so far, I do not get any errors or warnings. I'd like to do this, because I want to change a few things regarding the display and the user input. So, when I program the microcontroller with the successfully build .hex file, I get the same problem as before. The displayed temperature is stuck at room temperature. Am I doing something wrong? Because I saw that @afedorov managed to compile the source code (I assume he also tested if it works on his unisolder) with the free version of XC32 (which version, btw?), see this post.
Thank you for the whole support I got up to now, I really really appreciate it.
Hey guys, i struggle a bit in identifying wich pin is wich on J2, J3 and J9. The silkscreen doesnt really help in terms of orientation like with J4 and J8.
Sorry, no picture from me, but text information. All "directions" when you've got the PCB with the silkscreen oriented towards you, so readable to you: J2: top right: vout2+ bot right: vout2- top left: vout1- bot left: vout1+
J3: top right + bot left: GND bot right: -0.6V top left: 3.3V
J9: don't know this one, but using the gerber files you should easily be able to find out.
it's been a while, I've been doing a few other projects, but now I've come back to my Unisolder.
As a reminder: Everything worked so far (analog path was ok, all MOSFETS ok, tip is ok (heats up), handle is ok, no shorts or otherwise faulty solder joints visible). But, everything I plug the handle with the tip into the station, the displayed temperature is stuck at room temperature, ever though the iron is rapidly heating up. When in calibration mode, the PC software shows this:
Looks very nice, this makes me believe that the analog path is definitely working as intended. The following image is from the PC software when I connect the handle with a tip inserted:
The ADC value again is as intended (or at least I think it looks as intended), but the current temperature graph is absolutely wacky. To my understanding this should be a more or less smooth line, too, right?
So, that was the situation back in may (last message). No I finally ordered a new µC, in the hopes that I had just in some strange way fried the PIC and replaced it.
Well... No. Either the old PIC was absolutely ok or I got another broken one with exactly the same defect. Unlikely. I've played around a bit with my MPLAB compiler settings and tried enabling optimization (-O2), but that did not change anything either.
So, to my understanding basically the problem is the "conversion" from the ADC's value to the temperature value. Is there ANY hardware, besides the µC, involved into this conversion? I basically already replaced everything bu the crystal, but I think if the crystal was defective I'd be having far more problems. I couldn't find anything from the schematics, bus I'm no experts on pic, maybe there is something external involved. Or does some pin, besides the ADC pin, on the µC have to be in some state for the temperature conversion to be triggered or working properly? I think I can rule out the µC being defective. But to be honest, I am having a really hard time understanding the firmware code, I think other people here have a far firmer understanding of the code. And help or guidance is appreciated.
I've done a few additional measurements, this time with a scope. And, by now I actuall tend to agree with both of you. All signals I measured look ok to me, everything points to a faulty MCU. First I did not believe it to be the MCU, because it was brand new, purchased at digikey or farnell (don't remember, but definitily either of the two), so I sure hope it's no chinese copy. Sadly, I do not have a replacement at hand right now. But, I wanted to order a few things at digikey anyways, so I guess I'll just get another PIC and try to replace it. Will report back to you guys as soon as I have my replacement and soldered it in place.
Again, heaps and heaps of thanks to you guys for bearing with me! I really do appreciate it.
Edit: For completeness sake: Yes, the voltage reference is rock stable at 2,978 V. It is a little less than 3 V, but I guess it's ok. It would only lead to a slight offset in the termperature measurement.
It should be logic "0" (at least less than 0.8V ) in cal. mode. That's mean firmware or U5
Yes, that's what I tought. As I said, it was either U5:2 or U5:3, after reflowing it works properly now.
The temperature now rises beyond room temperature, but it is very, I don't know how I should call it... jerky? It jumps around wildly, every now and then a realistic temperature value pops up on the display, but mostly it's rubbish. I've tried to capture it with the software by logging the data through USB, I've attached the screenshots. "Calibration.png" shows the data acquired in calibration mode. Looks very good. "wCartridge.png" shows the data logged during heating. And this is the one making absolutely no sense to me. The ADC value looks perfectly fine. The "Current Temperature", "Filtered Temperature" and "PID Temperature" on the other hand make absolutely no sense to me. How is it possible that they deviate so much from the ADC value's behaviour?
now, that is a very interesting thought, and it also seems to be the right place to start looking. Because, the voltage across C10 is 0,7 V, which in my opinion is everything else but close to 0 V. Tracing the problem back to the µC lead me to a broken pulldown resistor for U3 (R21 was bad). Replacing it did not change anything, but ONOFF seems to be having a duty cycle of 50% (at least the voltage of the ONOFF trace is ~1,7 V, measured at U3A:2 and U5:2).
As I am writing this, I reflowed pins U5:2 and U5:3. That solved the temperature problem, indeed. Now, onto the next problem: the lab supply I'm using seems to struggle with providing the required power. It did work in the past, it's specified for up to 8 A, but I guess that's a problem not related to Unisolder but rather something I have to solve on my end. The supply is like 30 years old... Will report back testing with a different supply.
For now I really want to thank you guys for supporting me and leading me to the solution!
so, I reflowed everything as promised the other day. But, no change, the temperature still is only room temperature. But, as an added bonus now the USB communication works, which previously did not work (found that out shortly before reflowing everything).
But, I have got an interesting change. Now the iron starts heating, even when I am in cal mode! Before it just showed me the TC voltage without heating. Now it starts heating the instant I plug the iron + cartridge in, no matter if I am in cal mode or normal mode.
Another very interesting thing I absolutely cannot make sense of is the iron ID. When I connect the handle only (without cartridge), it correctly shows 24 5 as IDs. When the cartridge is inserted, this changes to 24 8, even though "JBC C245" is still displayed as tool in the top of the display. And, as I said, it instantly start heating, even in cal mode...
What is left - U5 for a re soldering or a replacement
I completely resoldered U5, sadly without a change. U5 is brand new, I replaced it a week ago. I cannot replace it at the moment, because I do not have a replacement at hand.
Tomorrow I will reflow all components on the PCBs with a hot air soldering station, if that does not help I might retry using an reflow oven. But right now, I again am without the slightest clue, what might be wrong with the board.
I've just tried to heat up C245 with hot air @270*C and got ADC value around 250, maybe it helps somehow.
That helped tremendously, indeed! Thank you! Now I know the wiring is ok and the OpAmps work correctly. When I let the tip heat up for around 3-4 seconds, I get a similar ADC reading, slightly above 220, seems to be about right. So in my eyes now the wiring is ok, the OpAmps are all ok and the cartridge is ok.
kage-chan, try to check U13B or replace U13, check Vshunt line for a connection and proper soldering resolder Rs1
Nice idea. From Rs1 up to U5:12 every trace, solder joint and connector has continuity and a very low resistance (not measurable with my DMM). While heating up the iron, I can measure about 500 mV at C59 with my DMM in DC mode (yes, I know, wrong tool, but that's all I got at hand right now). So that shows me that the vshunt path is doing at least something. Next time I get an oscilloscope in my hands I'll try graphing the voltage at C59. In Cal mode all voltages along the vshunt path are zero in my case. To me, from the schematics it makes sence, but can somebody confirm that?
tried reversing the red and green wires ind the handle's connector, still, no change.
As for the FW, I am still using sparkybg's code from the original post, which hasn't been update for quite a while. Might that be an issue? You guys seems to be working on the FW...
It just came to my mind, I did modify the FW before, because I'm using a different display (SSD1603, twice the size of the original, had to flip text). I'll check with the original FW again, even though, I honestly don't think I broke it THAT much...
Edit: Ok, just tried the original FW from the first post without any modifications, no success either. Does anybody have a list of TC output voltages for different temperatures (including RT, please) for the C245 cartridges? And, can anyone point me to the place in the FW code where I can change the delay between turning off the heater and measuring the TC voltage? Would try increasing the settling time for the TC...