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

[jonasius]

• Please check if the PR fulfills these requirements

• 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

• Startup is slow, black screen for a few seconds, maybe due to PD negotiation issues?
• 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.
• OP_AMP_GAIN_STAGE 536 needs to be adjusted according to the 22k resistor instead of 51k
• Documentation needs to be updated
• Maybe source/Code/BSP/Sequre_S60 folder should be renamed to Sequre?
• 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]

👍🏼

[Ralim]

This seems sane to me at a read.

[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

[schinken]

Connected to MacBook:

PD Debug
State 1 1 21
1  5V 2.0A

(Nothing else available when pressing Button)

Connected to Phone:

Stays off now...

Connected to Anker 775 GanPRIME 65W Laptop Port:

PD Debug
State 5 4 21
1  5V 3.0A
2  9V 3.0A
3  15V 3.0A
4  20V 3.0A
5  3-11V 5.0A

Connected to Anker 775 GanPRIME 65W Other Port:

PD Debug
State 5 4 21
1  5V 3.0A
2  9V 3.0A
3  15V 3.0A
4  20V 3.0A
5  3-11V 5.0A

Hope this helps somehow... let me know what else I can do to provide info

[jonasius]

...
Hope this helps somehow... let me know what else I can do to provide info

@schinken that indicates that the communication with the PD chip is working as expected.

IronOS/source/Core/Threads/OperatingModes/ShowStartupWarnings.cpp

Lines 86 to 92 in c19e882

	if (!FS2711::probe()) {
	if (getSettingValue(SettingsOptions::PDMissingWarningCounter) < 2) {
	if (warnUser(translatedString(Tr->NoPowerDeliveryMessage), buttons)) {
	cxt->scratch_state.state1 = 4;
	nextSettingValue(SettingsOptions::PDMissingWarningCounter);
	saveSettings();
	}

Thats the code which shows the warning. I remeber that it showed to me as well. But now it's gone for both of my Irons.

I assume that you are still getting the "No USB-PD IC detected!" message?

Maybe the probing which I use for detecting I2C devices causing a locked bus or prevent a second probing? I could try to add an additional unclogging sequence.

[discip]

@jonasius

Maybe you could try to reset settings to factory default.

Did that and also tried f21630e, but in both cases the result remained the same as mentioned here: #1920 (comment).

@Ralim
Any idea? 😊

[jonasius]

@discip
I think the probing is not working correctly. I observed that the I2C probing for the startup warning mentioned above never returns true on my irons. The first probing for selecting the I2C bus number is working on both of my irons with the current implementation.
https://github.com/jonasius/IronOS/blob/ae21be2913c63e0e92a3a1cb46d8eb522fba5748/source/Core/Drivers/FS2711.cpp#L52C1-L59C2
But if I reverse the probing, I2C communication with the PD IC isn't working with both of my irons, which is very odd.

With the current implementation the "No USB-PD IC detected!" message is only shown twice.

[discip]

@jonasius
Thank you for the report.

Though please keep in mind that we are using different hardware: #1920 (review)

Result is still the same:

PD Debug
State 0 0  0

I'm using the following power supply: Anker Nano II 65W.

[ReimuHakurei]

My S99 v1.3 never successfully negotiates PD. It does the boot looping with 0 0 0 -> 0 0 21 -> reset infinitely. This is using a 65W Dell USB-C power adapter. I do have a a higher-power adapter on the way so can test again with that when it arrives.

Board photos:

[kergitthecoder]

My S99 v1.3 never successfully negotiates PD. It does the boot looping with 0 0 0 -> 0 0 21 -> reset infinitely. This is using a 65W Dell USB-C power adapter. I do have a a higher-power adapter on the way so can test again with that when it arrives.

Board photos:

Happens with my S60P even on stock. PD and PPS both, I have used xiaomi and spigen 35w power supplies. I contacted sequre, they told me to try 65w+ supply. I did, and it doesn't reboot anymore.

[discip]

@jonasius
Would you mind resolving the conflicts?

@Ralim
Any idea for a solution to this? #1920 (review)

[jonasius]

@jonasius Would you mind resolving the conflicts?

@discip I'll within the next days. I'll also try to figure out the error with faulty I2C communication.

My S99 v1.3 never successfully negotiates PD. It does the boot looping with 0 0 0 -> 0 0 21 -> reset infinitely. This is using a 65W Dell USB-C power adapter. I do have a a higher-power adapter on the way so can test again with that when it arrives.

@ReimuHakurei I would assume that resetting without the iron heating is ether a wrong timeout or a bad USB-C cable. I have a silicone cable which shows such behaviour on a charger which is working fine with another cable. Some cables show weird stuff, one cable of mine only works in one specific orientation.

[ReimuHakurei]

Looks like it does work with a 140W EPR power brick so it must just not like the Dell charger for some reason -- odd as that generally works fine on other devices.

[Ralim]

The No-PD IC detected warning is only shown 3 times fwiw, so if looking into that you will have to do a settings reset under the advanced settings to get it to show up again.
If thats showing up but pd is "working" then its likely just the probe timing out somehow at first boot-check

[jonasius]

@discip if you want you can test the following build and see if the PD ic communication is working with your S60P.
https://github.com/jonasius/IronOS/actions/runs/10289925091

[pineapple-academic]

As a new user of IronOS, I want to thank you for your passionate work. I just flashed the build from jonasius/IronOS/actions/runs/10289925091 on my new S99, and the first issue I encountered was when I flipped the display orientation to left-handed. The idle screen seems to be experiencing some graphical issues.

[discip]

@jonasius
First of all, thanks for still working on it. 👍

Unfortunately, the result is still pretty similar:

PD Debug
Status 0

[discip]

@pineapple-academic
Please open a new issue as the one you described above is not related to this PR.

@Ralim
Confirming this issue!

[thetooth]

Just a heads up, the work done here seems to have fixed my OG v1.0 S60P, which uses the same PD IC as v1.5 S99 and identical board and other components to the v1.4 S99.

Takes about 600ms to reach target temperature now lmao.

[jonasius]

@discip
Could you check if the "No USB-PD IC detected!" message is shown with the latest build of this PR after flashing, remember it is just shown 3 times.

Just a few quick notes.

• Current implementation probes on I2C bus 2, and if PD IC is present it will set bus 2. Otherwise sets bus 1 for PD IC.
• Later in the code there is a second I2C probe on the previously set bus, this information is used for showing the "No USB-PD IC detected!" message.

For testing purposes I reversed the detection. Probing on bus 1, if present setting bus 1, otherwise setting bus 2. Interestingly with this procedure negotiation fails on both of my S99 (one with USB-PD IC on bus 1 and the other with USB-PD IC on bus 2). But only one iron is showing the "No USB-PD IC detected!".

Based on that I will investigate further within the next days.

[discip]

@jonasius
Sorry, I somehow forgot to comply with your request. 😔
The answer is:
No, the message NO-PD is not displayed even after a reset.