Add support for SEQURE S99, and new Rev. of S60P

[jonasius]

• Please check if the PR fulfills these requirements

• [x] The changes have been tested locally
• [ ] There are no breaking changes

• What kind of change does this PR introduce?

• Add support for Sequre S99

• What is the new behavior (if this is a feature change)? IronOS booting on Sequre S99

• Other information: Currently work in progress.

Problems / Todo

• [x] Startup is slow, black screen for a few seconds, maybe due to PD negotiation issues?
• [x] Negotiation of PD seems to have a problem. Tested with multiple Apple USB-C Chargers.Always uses 5V QC. PD Debug at startup shows State 0 0 21 multiple times, with blinking/resetting screen, after a while showing State 4 1 21.
• [x] OP_AMP_GAIN_STAGE 536 needs to be adjusted according to the 22k resistor instead of 51k
• [x] Documentation needs to be updated
• [x] Maybe source/Code/BSP/Sequre_S60 folder should be renamed to Sequre?
• [x] Better thermo model for tip temperature measurement?
• [ ] Tip selection option to allow usage of 5.5 Ohm tips?

[Ralim]

Hia,

This is great progress.

The black screen at startup is odd. PD negotiation shouldn't block boot. Is it possible its being restarted rapidly with flaky USB-PD?

(Do you have any tools for debugging USB-PD)?

I haven't really worked on the FS2711 driver much so not sure how best to debug it other than trying to parse the code to match up to what you see.

[jonasius]

Hey, yeah. It seems to restart rapidly. It seems to be especially with the Apple Chargers. Another charger I tried let the iron boot straight up. I hope I can investigate further this weekend.

Sadly I don't have special USB-PD tools. Maybe I need to get something or build something to hook a logic analyzer on?

As I could see with the debug menu, when it comes up it gets all available PD modes, but stays in 5V mode. I think I need to take a look at the measurement of the tip for the power calculation? Maybe you can give me a hint on that?

[jonasius]

@Ralim I'm currently digging a bit through the code and debug outputs of the iron. I wondered why it reports PWR QC instead of PWR PD. I think at least I need to extend the getPowerSourceNumber funciton with a ifdef for POW_PD_EXT.

Regarding the PD negotation problem with my Apple 60W USB-C PSUs I tried to increase the PROTOCOL_TIMEOUT to 200 ms, which helped. The Iron boots instantly. PD Debug First Shows State 0 0 21 but quickly changes to State 4 1 21, without a reset/screen flicker. What I noticed when I switched through the PD debug menu and viewed the capabilities was that before increasing the timeout, the PD debug menu showed an entry with no voltage and only amps specified. That entry isn't showing up with the increased timeout.

I hope I can make some progress tomorrow.

[Ralim]

I'm currently digging a bit through the code and debug outputs of the iron. I wondered why it reports PWR QC instead of PWR PD. I think at least I need to extend the getPowerSourceNumber funciton with a ifdef for POW_PD_EXT.

Ah heck, yes that will fix the issue

PROTOCOL_TIMEOUT should have been wired up to the PD timeout we already have thats user adjustable. If you want I can wire that up (or you can of course). I default to 500ms for normal pd.

[jonasius]

PROTOCOL_TIMEOUT should have been wired up to the PD timeout we already have thats user adjustable. If you want I can wire that up (or you can of course). I default to 500ms for normal pd.

@Ralim It's a bit unclear to me. In the Settings.cpp PDNegTimeout default value is 20, max 50. If I got the description right it should be in 100ms steps, so default is 2000ms? :-o

OP_AMP_GAIN_STAGE 536 needs to be adjusted according to the 22k resistor instead of 51k

How did you determined the value for the OP_AMP_GAIN_STAGE? ~I measured/calculated it roughly to 226 for the different feedback resistor. I don't get exactly how the two OP-Amps are connected.~

[Ralim]

so default is 2000ms? :-o

Ah sorry, I think we raised the default later on.

How did you determined the value for the OP_AMP_GAIN_STAGE This number is calculated as being the "gain" of the op-amp.

In the S60, its two sequential op-amps chained. Both are configured as non-inverting amplifiers.

Input op-amp has feedback resistors of 9.31K and 1K. (therefore gain is 10.31) Second op-amp has feedback resistors of 51K and 1K. (therefore gain is 52).

So 10.31 * 50 = 536.12; so the define is set to 536

[Ralim]

Let me know when you are happy with this by marking it ready for review 🙇🏼

[jonasius]

Let me know when you are happy with this by marking it ready for review 🙇🏼

Nice! I'll try to fine tune the temperature coefficient beforehand. Add documentation / the S90 to the supported irons table and fix the remaining clang style mismatches.

[jonasius]

I compared the temperature at a setpoint of 320°C to a original JBC station. In my eyes the coefficient is okay for a first shot.

Then I observed that the name and description for PDNegTimeout and USBPDMode are not shown in the menu. I quite don't get it. The menu Item is here

I got a second S99 which is V1.5 instead of V1.4, it seems that they changed something. Although a FS2711 is used, it does not negotiate PD. I quickly took two picutes:

[jonasius]

@Ralim, I tried your increased pwm speed. Works great on the S99! No more restarts, even with power limit set to 60W on a 60W USB-C charger.

What I got so far regarding v1.5

• There is a detection of HW version in the original FW
• I2C to the FS2711Q connection seems to use the same pins
• Just to make sure I checked the bootloader, it is also the same on the v1.5 iron
• PD-Debug shows only zeros

[Ralim]

@Ralim, I tried your increased pwm speed. Works great on the S99! No more restarts, even with power limit set to 60W on a 60W USB-C charger.

Glad it helped for you, definitely helped me on my units here (S60/S60P)

What I got so far regarding v1.5

* There is a detection of HW version in the original FW

Could maybe do a quick look around to see if a GPIO is grounded (common method of detection)

* I2C to the FS2711Q connection seems to use the same pins

* Just to make sure I checked the bootloader, it is also the same on the v1.5 iron

* PD-Debug shows only zeros

Eugh messy, Looking at the photographs not a whole lot stands out to me, looks more like a minor update. Is the tip being detected in the new revision? Some logic is held and doesnt run until after that finishes

[foosinn]

• PD-Debug shows only zeros

The Sequre S60P V1.2 has exactly the same issue for me. It also seems to have the same board as the S99P o.O

[jonasius]

* I2C to the FS2711Q connection seems to use the same pins

Checked on that again. I was wrong. On V1.5 I2C connection for the FS2711Q is on different pins:

• SDA is on PB10
• SCL is on PB11

On V1.4 these pins are floating. I found no other pins directly tied to GND or VCC so I think we need to use the I2C pullups on PB10 and PB11 to determine if the second I2C bus is present. As an alternative we could probe for the FS2711. If it's there there is no need to switch the bus.

[foosinn]

How would theese be configured?

#define SCL2_Pin              GPIO_PIN_11
#define SCL2_GPIO_Port        GPIOB
#define SDA2_Pin              GPIO_PIN_10
#define SDA2_GPIO_Port        GPIOB

I'd like to try on the S60P 1.2

[jonasius]

I'd like to try on the S60P 1.2

@foosinn If you want to test, without any warranty, you can try to use the following build for S60P https://github.com/jonasius/IronOS/actions/runs/9666708069/job/26666844382

[foosinn]

Awesome

PD Debug
State 5 5 21

I guess that's what we hoped to see?

[foosinn]

I think there is currently a off by 1 error in the menus. "advanced settings" brings me to "user interface"

[jonasius]

I think there is currently a off by 1 error in the menus. "advanced settings" brings me to "user interface"

I'll try to look into it. On my S99 it is fine.

The experimental fix feels hacky. @Ralim do you have a advice for a clean solution?

[Ralim]

@Ralim do you have a advice for a clean solution?

Assuming you mean for detecting the I2C bus pins? If so, your going to need approximately that logic somewhere. I don't think that is a bad way to locate it; at least for now. Abstracting it out into some form of mux'ed I2C is going to add more overhead for not much gain. So while its just one class that has to handle this I dont think its worth overthinking too much.

I would probably make sure all probing is done as early on as possible to ensure things dont end up racing on it.

I think the current code will handle a missing device without crashing so no issues there.

I think if I was focusing on being cleaner I might abstract it into an I2C object that takes two classes and merges them like that based on which one ack's work for. But also I dont think its going to be worth the overhead at this point in time?

[foosinn]

Hey,

on the S60P the first menu is called "Soldering Settings" but the first option in it is called "PD Timeout".

Seems like there is just the first menu missing?

Otherwise it seems to be working really nicely. Awesome work :)

[jonasius]

Hey,

on the S60P the first menu is called "Soldering Settings" but the first option in it is called "PD Timeout".

Seems like there is just the first menu missing?

@foosinn I think I found it.

I think the S60P could also handle DC input. Are you able and would like to test it?

[foosinn]

Menu is fixed, awesome :)

I think there are maybe some calibration issues. Running from DC the Temperature is not really stable. Also i feel like the iron is getting quite hot in the middle (around the first button).

Using PD the Iron still gets warm, but not nearly as hot when compared to dc (PD at 21V, DC at 20V on Makita Battery)

The original firmware seems to stay cooler in every case, could this be caused by the faster PWM?

[foosinn]

could this be caused by the faster PWM?

I don't think this is the reason, especially on DC the iron still gets really hot, even with e6a3f380 reverted.

[discip]

@jonasius Could you please resolve the conflicts?

[jonasius]

@jonasius Unfortunately, this PR breaks PD for the S60P v1.0. No matter which PD timeout or PD mode. The only available voltage is 5 V.

PD Debug
State 0 0  0

Ah damn. Thats not good 😞 Whoch version is the one which works on your iron?

[discip]

Oh, I seem to have missed to check whether it ever did negotiate for PD, as I just noticed that it negotiated for 8 V QC (debug menu) with this build: https://github.com/Ralim/IronOS/actions/runs/9439985072.

While it should negotiate for either 15 V (4 A) or 20V (3 A).

PD Debug
State 6 5 20

@Ralim Did you get your S60P to draw all 60 W?

[jonasius]

While it should negotiate for either 15 V (4 A) or 20V (3 A).

PD Debug
State 6 5 20

@discip is that the PD Debug output with both versions? From that we could assume that the communication with the PD IC works.

[discip]

@discip is that the PD Debug output with both versions?

No,unfortunately that is only on the build I linked above.

[jonasius]

No,unfortunately that is only on the build I linked above.

@discip I checked the code. Can't figure out why it doesn't work. It should. Maybe @Ralim has an idea on this.

I once observed a non reproduceable strange behavoiur after updating. My iron wasn't able to negotiate with PD. Maybe you could try to reset settings to factory default. I didn't tried that because I flashed back the original bootloader, and flashed the image again which resulted in a complete reset and default settings. Maybe worth a try?

[foosinn]

https://github.com/Ralim/IronOS/actions/runs/9439985072.

I also just flashed this build. It's neither working on the S60P 1.2.

f21630eb79768a43fb73a5259e548031380ad1cd still worked for me