Closed tuna-f1sh closed 4 years ago
Hey, nice to hear that you've successfully built an otter-iron pro!
This is strange, such a bug is usually caused by a buggy version of GCC, but version 10.1 is actually quite good and should work! I use gcc v9.2.1 and I have not encountered this issue.
Since the d-term is not used you have the following options:
Thanks. Yes I agree very odd, I verified a few times to make sure I wasn't doing something stupid. I'll give it a bit more digging when I've got time. I also plan on implementing some STUSB4500 features such as detection of valid PD profile before attempting to power the iron.
I had the system working by removing the line, as you say but just wondered if anyone else had experience this. I couldn't use the pre-built binary because I needed to limit the current to 3.0 A rather than 4.0 for my 65 W USB-PD upstream device.
I had one unrelated question: How did you select the tip offset and coefficient? Did you use a thermal sensor? Do you think the values are representative for another C245 handle and tip?
Did a bit more testing to see if I could get to the bottom of this, for personal knowledge if anything. The watchdog is biting and resting the system so that line is taking too long for some reason:
r.cycletime
with 1.0 - this fixes it.r.cycletime
of 0.0000725 causes the calculation to take too long and the watchdog to bite. Since the Cortex-M0 doesn't have an FPU and it's a divide operation, seems plausable. Not sure why it's only happening on my build with GCC 10.1 though. Tried setting optimisations to O0
but same result. Anyway, not got more time to sink into this since it's not even required with the current build missing the D term but would be nice to know the cause! Feel free to close this.
I have a fork with ST4500 setup for PD (allows it to work with kosher PD adaptors like Apple MacBook), better iron detection based on outside dead-zone current and (I think) correct OLED setup (I had problems with screen start-up on some boots with current firmware). Let me know if you want a pull request.
I couldn't use the pre-built binary because I needed to limit the current to 3.0 A rather than 4.0 for my 65 W USB-PD upstream device.
All power supplies that I use also provide only 65W, I've set the current limit to 4A because it is slightly off. My the f072 does not have enough peripherals/peripheral events to sample the current while it is flowing (Mosfet on) and the temperature, which needs the mosfet to be turned off. I couldn't come up with an elegant solution, thus I implemented the measurement to run in sync with the PWM, right before a new cycle starts. This solution would measure no current, if the frequency would be the same as with my TS100 clone (~10Hz). To be able to measure and limit the current, the frequency has been increased to 10kHz and a smoothing capacitor was added. This works (for me) with a empirically measured current limit of 4A :D
I had one unrelated question: How did you select the tip offset and coefficient? Did you use a thermal sensor? Do you think the values are representative for another C245 handle and tip?
Yes and probably! You can set both values to zero, measure the tip temperature at room temperature and use the difference as offset. For the coefficient set the tip temperature to whatever (>100°C) your temperature measuring device can handle and calculate the multiplication factor to match both temperatures. This does not need to be exact since +-5 degrees or more usually won't hurt your board/parts.
Let me know if you want a pull request.
Yes please! Especially the PD detection has been on my todo for a long time now and I've heard from many people that the display causes problems! Thank you very much for your effort! :)
May I also merge your code into the firmware of the Otter-Iron? I want to add a "select-the-highest-possible-voltage" function, allowing the use of 9V and 12V power supplies. (schema: Try 20V, if not available try 15V, 12V, 9V)
Also thanks for the info on the D-Term, which is really a strange and interesting bug. I won't pursue this any further and close the issue.
Built up this assembly with no problems - great build, thanks!
Had issues bring the firmware up however. The system would crash and reboot just as it entered the deadband and PID control kicked into life. Some brute force debugging commenting out lines, it appears to be at the differential error calculation:
r.derror = (r.error - r.errorprior)/r.cycletime;
Removing this line it works fine. Can't figure out why? Thought maybe divide by zero but cycletime is constant non-zero. The differential term isn't even used by default so it is not even doing anything of use. It's not due to a brown out as I even tried it without using the calculated duty setting and it still falls over (might be related to crashing without tip installed?).
I guess you've not encountered the same issue? I'm using GCC 10.1.0 so might be due some compiler optimisation?