TS80P Constant Power Cycling

[sdaitzman]

I have a meeting in 1 minute, but here are the details of the power cycling issue I'm seeing for now. I'll update later with more information.

• I'm submitting a ...

  • Bug report
  • Feature request
  • Translation

• Do you want to request a feature or report a bug?

Report a bug.

• What is the current behavior?

After flashing the latest release TS80P firmware (not beta 3) I'm seeing extremely rapid power-cycling. The iron powers on and off over and over again--it blinks on, just barely loads the main screen and then power cycles.

• What is the expected behavior?

Power on and allow soldering.

• If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem

Steps to reproduce:

1.DFU flash TS80P_en.hx from my Mac over a USBC cable
2.Plug TS80P back into Mac (it power-cycles endlessly)
3.Re-enter DFU mode and very, very quickly drag a default Miniware firmware hex from the forum onboard
4.Everything behaves normally.

Video of problem if hard to reproduce

I'll upload a video soon.

• What is the motivation / use case for changing the behavior?

• What are you running:

On the idle screen, you can hold the settings button and it will show you the firmware version.

• Firmware Version: 2.11.372FF8E3
• PCB Version: (1/2) unsure, where do I get this from?
• Power Supply (Voltage and Current Rating): direct from a 16-inch MacBook Pro, and from its 96W power supply.

• Other information

[dreawer]

Can confirm about the same behaviour on my TS80P on the latest firmware (2.11). Except in my case it blinks 3 times (miniware logo -> my custom logo x 3 cycles) and than all works great.

[Ralim]

Hi,

Can you confirm if this issue was present on beta3 or not?

Also what power supplies have you tried?

I don't have access to any apple chargers to test here at the moment 😢

[sdaitzman]

@dreawer what charger hardware are you using?

[dreawer]

@sdaitzman

@dreawer what charger hardware are you using?

This one: https://a.aliexpress.com/_eKgHXj

[Ralim]

@sdaitzman @dreawer

Could you try the latest beta release to see if this works better for you 😅
Really hoping it works a bit better :)

[sdaitzman]

Thanks so much, @Ralim !

Unfortunately, I'm seeing a consistent failure to flash the new firmware. I've tried a bunch of times, so far. It always comes up with TS80P_EN.ERR or TS80P_EN.NOT.

Any advice for why this could be happening with this firmware update? Is there something I should be doing other than copying it using Finder to my TS80P in DFU mode?

[Ralim]

Hmmm.

No special magic that I'm aware of.

Are you doing the double copy, and also make sure to extract the zip first?

[sdaitzman]

What do you mean by double copy?

And do I need to extract, other than decompressing the original file to get the .hex and .bin in all those languages?

Thanks for the speedy response 😄

[Ralim]

You just have good timing 😅

Double copy:

Connect device in DFU
Copy hex file once
Device reconnects and has .ERR
Copy file again
Device reconnects and has ERR and RDY

Extract:
Just don't try and drag the .hex from inside the zip. Put the hex file in your downloads or somewhere.
You don't need any of the other files :)

[sdaitzman]

I managed to do the upgrade!

Unfortunately, it still has the same issue as before 😢

[Ralim]

Gah damnit.

:/

I might just have to order an apple power adapter to figure it out :/

Sorry about that

[sdaitzman]

Is there any other useful debug info I could provide from here?

[dreawer]

@Ralim , thank you!

For me it works better, no more blinking after connecting the power supply.
And no issues with flashing the latest beta.

@sdaitzman @dreawer

Could you try the latest beta release to see if this
works better for you 😅
Really hoping it works a bit better :)

[discip]

@sdaitzman
Would you please check, if the latest commit f3488d7 works for you, since there have been quite a lot of updates since your last reply.
And if so, please close this issue.
thanks

[sdaitzman]

Happy to check!

[sdaitzman]

Sadly still encountering the same issue 😞

[hhammarstrand]

I got my ts80p today, and got the same issue. It would just constantly power cycle.

I might have found a solution though.
I flashed this hex file https://github.com/Ralim/IronOS/actions/runs/492188523 (not sure if it matters if you use this version or the latest release, I did try the latest release first and that didn't work, and then I tried this one which didn't work until I did a factory reset) and then when connected directly to my laptops USB C port (5v) I did a factory reset. Disconnected and then it worked with an external power brick. I'm using the 18w power brick I got with an iPad Air (4?) latest gen

Would you mind trying this workaround @sdaitzman ?

Edit: I got curious to see if I could get the latest release on my iron and couldn't get it working again, until I tried the following:

• Flash latest release with swedish translation (_SV)
• Plug in and out the iron without entering DFU and let it start
• Flash the linked release without translation (_EN)
• Factory reset while connected to the 5v power source

I couldn't get this to work with the latest release of _EN instead of the linked one.

Edit (again...): had the iron sitting connected since I wrote the last update, and now it has began powercycling again. Reverted to stock firmware. Sad, because IronOS was way better! If I can provide any help to resolve this I would gladly help.

[sdaitzman]

Still encountering the issue, but I've made several odd discoveries that I think could help:

I'm still encountering the same issue, and wanted to clarify that the power-cycling also occurs when the iron is attached to my MacBook Pro 16" with the USB-C cable it came with. It does not power-cycle when in DFU mode.

I also noticed that when heating to a high temperature, the iron sometimes maintains its status without crashing for longer periods of time, which seems odd to me?? It usually restarts every few seconds when plugged into my MacBook Pro power supply. Just now I was curious and tried powering the heat back on each and every time it crashed and rebooted. Once it reached around 300, it stopped power-cycling!! It stayed on for several minutes. I rebooted it and it started crashing again, but I upped the temperature and observed that it stayed on for a few minutes again. And, perhaps most strangely, it was able to enter sleep mode and begin ramping the temperature down to 150 (and is currently maintaining that) without any crashes!!

[sdaitzman]

Update: maintained for like 5 minutes of no-crashes, and when I picked it up just now it reheated to around 360 with no trouble!! This is a kinda questionable and unreliable workaround but it seems that once it's heated above a certain temperature, it's usable... any clue what could be causing that behavior? Happy to try additional things, send along a video, or do whatever else I can to help debug this ☺️

[hhammarstrand]

@sdaitzman do you get 9v or 5v out of your mbp? I get 5v from my lenovo, and it always works with that, both in dfu and when it's flashed. When I connect to 9v+ it does begin to powercycle.

[paulfertser]

On Wed, Jan 20, 2021 at 10:55:37AM -0800, Sam Daitzman wrote: Update: maintained for like 5 minutes of no-crashes, and when I picked it up just now it reheated to around 360 with no trouble!! This is a kinda questionable and unreliable workaround but it seems that once it's heated above

Your description mostly sound like a voltage drop when it starts to consume above a certain power threshold. Have you tried the power limiting feature? What did you set it to? Does it reboot even if it's just 10 W?

…

-- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercerpav@gmail.com

[sdaitzman]

Screen displays 5, but it reboots so fast (~1-2 sec max) I don't know if it's briefly negotiating a higher voltage and just hasn't updated :/

[sdaitzman]

@paulfertser I'm a little confused by that, but maybe I'm not understanding -- to be clear, it's working much more reliably when it is set to a high temperature.

I tried limiting power to 10W while plugged into the supplied power supply, then plugged into both my MacBook and its charger, and sadly no change in behavior at all.

[Pythe1337N]

Hi! I also have this issue and maybe can help by adding some information.
My MacBook Pro (13-inch, 2019) have this issue with both it's usb ports and the supplied charger.
However, my older MacBook Pro (13-inch, 2016) does not. Both the usb port and the charger works as expected.
Both changers are rated the same (USB-PD 3A @ 9V) but clearly they differ.

Summary:
Running v2.14.1

• MacBook 2019
  • Boot loop when connecting to laptop's usb port (iron displays 5V and reboots after ~1s)
  • Boot loop when connecting to Apple charger (iron displays 9V and reboots after ~3s)
  • DFU mode also stuck by boot loop
• MacBook 2016
  • Works when connecting to laptop's usb port (iron displays 4V reboot when trying to start heating)
  • Works when connecting to Apple charger (iron briefly displays 5V, reboots, then displays 9V)
  • DFU mode works as expected
• Chinese charger supplied with the iron (Travel Charger QC09)
  • Everything works as expected

Hopefully this might give someone a clue to what has changed with these chargers

[hhammarstrand]

I changed out my apple power brick to a Otterbox 18w instead and the standard firmware warns for low voltage, but IronOS works great! Finally!

[ffuubarbuzz]

I'm experiencing the same with 2019 MacBook adapter and pinecil.

[BuToNz]

Same issue here with: https://www.amazon.co.uk/gp/product/B07Q39W5JB

Latest version of the firmware. What's odd is maybe once in every 20 connects it will work fine and get 12v/30w. Some sort of handshaking issue?

[x70b1]

I have the same issues with a Lenovo 65W Adapter and the TS80P.

It looks like PD is a problem. Using a Qualcom Quick Charge 3.0 works fine. Runs at 9V.
Also the vendor firmware works with that Lenovo adapter.

[xoniq]

Got my TS80P today, I tried it on the Apple charger, worked fine, and heated to 300 in seconds. This was when brand new. After flashing this IronOS, it doesn't work anymore (same issue as OP), I re-flashed the OG firmware, and now it works fine again.

Any possible fix upcoming?

[xxv]

Just to add some data points for narrowing this down. I've got a TS80P that I purchased just a few days ago and installed 2.14.1 on it.

• Anker 30W PD port: gave me a boot loop (flash the miniware logo). The vendor firmware did not have this issue with the same power supply.
• The PD charger that came with the iron (model QC09, PD+QC3.0 45W): It starts on first boot and negotiates 12V.
• Lenovo 65W charger: takes 3 boots (flashes miniware logo three times) and only negotiates 5V (the charger supports 5, 9, 15, and 20V). I seem to recall this PD charger worked properly with the stock firmware.
• Anker 60W charger: starts on first boot, negotiates 9V.
• CanaKit 3.5A USB-C supply: starts on first boot, negotiates (honestly not sure if PD or not) 6V.
• Leviton T5633-W 15A outlet (non-PD): starts on first boot, 5V. (only supports 5V)
• Pixel 3a stock charger: starts on first boot, negotiates 9V.

That's all the USB-C power supplies I could find in the house. Based on this, fingers are pointing strongly at PD negotiation.

[alvinhochun]

You should test the build in PR #917

[xoniq]

You should test the build in PR #917

Ill try too with my Apple charger.

Edit; just replaced the hex, and well it seems to have solved with my Apple charger (Negotiating 9V).

Just before I flashed; I checked, and it failed on my Apple charger. 10s later updated, and working. Also let it reach the 320 degrees 2 times in a row.

[remi-sc]

I am experiencing similar PD issues on Samsung EP-TA845 45W PD Charger.

Stock miniware, and IronOS 2.11, 2.13, 2.15 behave the same way and power-cycles constantly when connected:

Tested on 3 different cables: stock silicone one, Unitek C14059BK and one another random C<>C cable I found laying around.
All cables showed the same behavior (+ flipping the connector did not change anything)

Stock charger works without issues.

The Samsung charger in question supports following modes (Checked on AVHzY CT-2):
PDO: 5V@3A, 9V@3A, 15V@3A, 20V@2.25A
PPS: 3.3-11V@5A, 3.3-16V@3A, 3.3-21V@2.25A
(PPS current limits printed on the charger itself are a little lower but volatages are the same)

Additionally when connecting through AVHzY CT-2 the behavior seem a little bit random (IronOS 2.15) - Sometimes the bootloop happens the same way, sometimes it negotiates 5V and sometimes It negotiates 12V (So I assume PPS kicks in once in a few tries???),
If I use PD-trigger function then I can get the iron to go into whatever mode I wish - 5/9 in PDO/PPS and 12V in PPS mode.

[remi-sc]

One more observation when connecting through AVHzY CT-2:
When boot-loop/power-cycling occurs then CT-2 does not show anything on the screen (it just flashes lightly)
CT-2 needs minimum voltage to operate - this lead me to believe that TS80P negotiates PPS at 3.3v - which is too low - hense power-loop

Having this in mind I attached an auxiliary micro-usb power cable to the CT-2 (pc port) - This allowed it to function even when the charger went below 5V.

lo and behold: I see that the charge voltage jumps between 0 and 3.3:

Would starting PPS negotiation at 5V help? (Or is it even possible?)
Or maybe the problem is that the current code decides that 3.3 is the max it can get?

[remi-sc]

I tried poking this by disabling PPS to at least force the iron to go to the PDO 5/9V (by setting this condition false):

IronOS/source/Core/Drivers/FUSB302/policy_engine_user.cpp

Line 100 in b1fd7eb

} else if ((capabilities->obj[i] & PD_PDO_TYPE) == PD_PDO_TYPE_AUGMENTED && (capabilities->obj[i] & PD_APDO_TYPE) == PD_APDO_TYPE_PPS) {

It didn't change anything.

Also tried forcing the 5V "negotiations failed" case:

IronOS/source/Core/Drivers/FUSB302/policy_engine_user.cpp

Line 142 in b1fd7eb

/* Nothing matched (or no configuration), so get 5 V at low current */

This also didn't change anything - power-loop still occurred.

[Ralim]

@remi-sc

Thank you for detailed debugging notes.

Few smaller bits :

• the iron doesn't transmit any PD messages on boot until it sees the charger start to send its capabilities message
• this means if a message is being sent from the iron that is causing the soft reset, the charger has already started to spam out its capabilities
• the charger sending these signifies it should be willing to accept them, and if it does not it should NACK rather than reset the power
• given ^, I would be mildly suspect of the charger not behaving in the expected manner

I would try delaying the start of the PD stack as a first step, to see if this charger requires a delay.

Does your inline meter support logging the PD messages?

You could also try disabling all of the selection logic so it selects slot 0 which will always be 5V.

However I suspect your not even getting to that point in the code tbh.

[remi-sc]

I would try delaying the start of the PD stack as a first step, to see if this charger requires a delay.

How would I do that?

Does your inline meter support logging the PD messages?

In theory it does, but it seems to be not working. I tried to record Lenovo laptop charging - PD definitely triggered but that garbage of a software did not record anything. It's windows only and the only install I have is an old un-updated windows 7. Maybe that has something to do with it...

However I suspect your not even getting to that point in the code tbh.

I think so too. On this charger I can't even go into a DFU/flashing mode. Which I would expect be completely separate from IronOS.

[remi-sc]

nevermind, I got the PD message logging working. No f-ing idea what changed.

Anyway:
Those are packets from a stock charger that works:

And those are the packets from the Samsung charger:

Other packets on the list are the same 2 packets repeated indefinetely

[remi-sc]

Note about packets from the samsung charger: It seems to be asking for cable capabilities and indeed the cable I used was Unitek C14059BK which is 20V@5A 100W rated PD charging cable as the second packet indicates

Edit: My inability to capture packets was due to a fact that capturing seems to work only in one usb-c connector position - so I had to flip it to make it work

[remi-sc]

What I wrote in my first post:

Sometimes the bootloop happens the same way, sometimes it negotiates 5V and sometimes It negotiates 12V (So I assume PPS kicks in once in a few tries???),

The successful 12V negotiation happens only when passing through CT-2 and only when the CT2<>TS80P cable connectors are in a "good" position - I have to try flipping both ends until I find right combination. From that point 12V is always negotiated. But if I enable PD packet recording then this negotiation stops working and power-loop returns. (No amount of connector flipping seems to work)

[remi-sc]

Additional PD message log when connecting a lenovo pd-trigger for laptops (4X90U45346) to this samsung charger:

We have the same 2 messages and then the charger transmits expected capabilities packet.

Using the exact same cable configuration results in power-loop on TS80P.

[remi-sc]

Checked another Samung charger: ep-ta800
No issues. The packets start with capability announcement similarly to the stock charger. No "discover_identity" packets.

[Ralim]

Hmm this is very confusing how it looks to be getting stuck on the SOP'/'' messages.
Currently the firmware is programmed to ignore the SOP' and SOP'' messages, and only listen for messages directed to it.
So really confused why the charger insists on sending out so many SOP messages.

Honestly have no real wisdom on why this is occurring though.

Just to confirm in the capture with the bad charger combo, does it ever send a source capability message?

[remi-sc]

Just to confirm in the capture with the bad charger combo, does it ever send a source capability message?

Yes but not when TS80P is connected, As I wrote in one of the posts above:

Additional PD message log when connecting a lenovo pd-trigger for laptops (4X90U45346) to this samsung charger:

The log from that comment was gathered with this setup:
{Samsung charger} <--- C-C cable ---> {CT-2 Meter} <--- C-C cable ---> {Lenovo PD trigger}
And it contained expected capabilities packet

And as per that comment: I checked TS80P on the same setup just by swapping Lenovo PD trigger with the TS80P:
{Samsung charger} <--- C-C cable ---> {CT-2 Meter} <--- C-C cable ---> {TS80P}
The result was a power-loop with endless message log.

Now that I read some more I think those "SOP" messages are a result of an E-MARK chip in the cable. (Charger asking the cable what are it's capabilities)
For now I only have one non-E-mark cable so I can't really try logging without using at least one.

[remi-sc]

One more caveat regarding this:

Yes but not when TS80P is connected, As I wrote in one of the posts above:

This is only when pd-logging is enabled. If I disable pd message logging in the meter (physical switch) then the power-loop is random and sometimes it does negotiate 12V. (but obviously I cant log the pd messages)

Just to sum up the info:
A: {Samsung charger} <--- C-C cable ---> {TS80P}: power-loop
B: {Samsung charger} <--- C-C cable ---> {CT-2 Meter logging enabled} <--- C-C cable ---> {TS80P}: power-loop
C: {Samsung charger} <--- C-C cable ---> {CT-2 Meter logging disabled} <--- C-C cable ---> {TS80P}: either 5v, 12, or power loop (depends most likely on cable position)

I will try gathering a more complete picture of exactly which setups result in what but that will take a while.

ATM in addition to the TS80P + CT-2 meter I have those usbc cables at my disposal:

• Silicone stock C<>C one that came with TS80P
• 2x unitek C<>C C14059BK (5A)
• 1x random C<>C 5A cable (I think the one that came with the Samsung charger)
• 1 USB-IF certified C<>A amazonbasics USB3 cable
• few other random C<>A cables

If you want me to check any particular setup then let me know

[remi-sc]

I will try gathering a more complete picture of exactly which setups result in what but that will take a while.

Following up on what I wrote: From this point on I will start posting more structured info. The stuff I posted earlier is a mess an I imagine it is difficult to make any informed conclusion.

So let's start:

1. When using Samsung EP-TA845 power cycling/blank screen occurs on all tested firmwares - both stock (1.23, 1.27, 1.30) and IronOS (2.11, 2.13, 2.15, master - commit b1fd7eb)
   All further tests done on the commit above

2. I can confirm that the power-cycling occurs even with PD/QC stack disabled here:

   IronOS/source/Core/BSP/Miniware/Model_Config.h

   Line 40 in da7d558

   #define POW_PD

   
   Obviously I lose higher voltage options - stock charger works but does not display acquired voltage

3. Behavior when connecting TS80P directly to a charger using various cable configurations:

C-C cable	E-marker chip?	plug positions	works on EP-TA845?	symptoms on EP-TA845	works on stock charger?	EP-TA845 works with Lenovo 4X90U45346 PD trigger?
stock	no	All 8	no	blank screen or single, rapid part-screen miniware logo flash	yes (12v)	yes (20v)
Accura ACC2177	no	All 8	no	blank screen or single, rapid part-screen miniware logo flash	yes (12v)	yes (20v)
Unitek C14059BK	yes	All 8	no	rapid miniware logo flashing	yes (12v)	yes (20v)
unknown	yes	All 8	no	rapid miniware logo flashing	yes (12v)	yes (20v)
Amazonbasics B01GGKYR2O 3.1 A-C cable + A>C 4pin adapter (no CC pin)	no	4 positions with A>C adapter on the TS80p	no	blank screen	no (blank screen)	no
Amazonbasics B01GGKYR2O 3.1 A-C cable + A>C 4pin adapter (no CC pin)	no	4 positions with A>C adapter on the charger	no	boots past miniware logo, displays programmed custom logo, goes blank	yes (9v)	no
Amazonbasics B01GGKYR2O 3.1 A-C cable + A>C 4pin adapter (no CC, D+/D- pins masked)	no	4 positions with A>C adapter on the TS80p	no	blank screen	no (blank screen)	no
Amazonbasics B01GGKYR2O 3.1 A-C cable + A>C 4pin adapter (no CC, D+/D- pins masked)	no	4 positions with A>C adapter on the charger	YES	stays at 5V	yes (5v)	no

A>C adapter in question:

4. When looking at those Vbus voltage graphs displayed on CT-2:
   
   I measured how long do those reset cycles last.
   When using a cable with e-marker chip it is ~353ms per cycle and when using one without it is ~273ms per cycle.
   So I presume the difference between "flashing logo" and "blank screen" when using different cables is most likely due to SOP-messages delaying the reset cycle by ~80ms (logo has a chance to start being displayed)

5. My previous remarks about the charger supplying 3.3 volts were bogus. The meter shows voltage graphs in 2 modes:

• Vbus voltage + current. This clearly shows 5v cycles
  
• D+ / D- voltages. Those cycles are at 3.3v / 2v range
  

[Ralim]

Alrighty, the table does make things a lot easier.

Yes but not when TS80P is connected, As I wrote in one of the posts above:

I was meanting that in the TS80P <-> charger, does it ever send anything other that SOP messages to the e-marker; just wondering if its something like it sends 50 then the soure capabilities, or if you are never seeing source capabilities sent.

I can confirm that the power-cycling occurs even with PD/QC stack disabled here:

So, this may be a problem then.
If that is turned off then this custom firmware wont do any communication to the FUSB302 PD PHY ic that is used to talk to the charger. This means that the FUSB302 will just be in its default mode of having the current sink pulldowns on the CC pins (used to trigger 5V).
If with that turned off you are still not able to maintain a flat 5V then it is extremely likely that its out of the control of this firmware as it means the power supply is tripping off before the custom firmware has booted / configured itself.

I'm mildly suspect this may be due to how long the Miniware DFU takes on the TS80P but I have zero proof of that.
Because of the delay they have added when it shows their logo, it means that negotiation cant start until a few 10's of milliseconds after that logo disappears. If your charger is too impatient to wait that long then the custom firmware may never have a chance to negotiate. I also cant rule out if their bootloader does anything to the FUSB302 as I haven't disassembled it and they wont give me the source (I did try).

Now, given this is a Samsung charger that they clearly dont market as a general USB PD charger, its quite possible its not certified and may have issues in certain cases. There are lots out there that have issues in their PD implementation.

Now, adding to this, you have indicated (if i read correctly :) ) that when you add the logger to the loop it will sometimes work.
I'm wondering if there is an issue with either the power output from the charger for VConn for the emarkers or perhaps an issue with how its detecting the pulldowns in the FUSB302 and its instead requiring more pulldown current than its typically provided by the FUSB302.

I dont have a good idea of the top of my head to prove that otherwise unless you feel like making a hacked up adapter to add some resistor pulldowns to the CC pins (normally its ~5.1k, but maybe 10k would work?) but I also cant promise you that will work either.

Honestly, I'm a little confused as to exactly whats going on here, especially as you are not seeing a source capabilities message (i think) when connected to the TS80P.

Another thing to try would be to log the PD messages when you boot the TS80P into DFU, as, as far as I know the DFU runtime wont touch the FUSB302 and thus it should act as a "dumb" PD device. This should cause the power supply to spam the source capabilities message for at least a few seconds.... should.

USB A->C cables can never use PD as they are missing the required connections. QC may still work, but its a bit of a nightmare standard so I recommend avoiding it where you can :)

Now that I read some more I think those "SOP" messages are a result of an E-MARK chip in the cable. (Charger asking the cable what are it's capabilities)
For now I only have one non-E-mark cable so I can't really try logging without using at least one.

Absolutely spot on. These messages are the charger trying to figure out the cables capabilities, so it can "downgrade" (limit) what it advertises to the lower of its own ability or the cables.

[remi-sc]

I was meanting that in the TS80P <-> charger, does it ever send anything other that SOP messages to the e-marker; just wondering if its something like it sends 50 then the soure capabilities, or if you are never seeing source capabilities sent.

This is confusing and annoying but the answer is that it depends: The meter I have behaves differently depending on whether PD message logging is enabled. If I enable it then no, I do not see any non-SOP messages with TS80P (for several minutes). If I disable the logging then on some cable positions I can get 12V on the TS80P negotiated (just passed through the meter). I suspect that this is because the meter is somehow holding the charger thinking there is something connected. While TS80P makes the charger think it is disconnecting or does something that leads it to go to "safe0V" temporarily (and repeat).

Given the above I will try to make a second similar table with the meter connected to make things clearer.

If with that turned off you are still not able to maintain a flat 5V then it is extremely likely that its out of the control of this firmware as it means the power supply is tripping off before the custom firmware has booted / configured itself.

Yup. That is my suspicion as well.

Now, adding to this, you have indicated (if i read correctly :) ) that when you add the logger to the loop it will sometimes work.
I'm wondering if there is an issue with either the power output from the charger for VConn for the emarkers or perhaps an issue with how its detecting the pulldowns in the FUSB302 and its instead requiring more pulldown current than its typically provided by the FUSB302.

Yes, it sometimes works with the meter, I will try to make a second table to document what are the exact circumstances when it works. My suspision is that TS80P is behaving is a way that makes the charger think it was disconnected. And adding an externally-powered inline meter somehow makes sustains the connection which allows for the boot/negotiations to finish.

I don't have a good idea of the top of my head to prove that otherwise unless you feel like making a hacked up adapter to add some resistor pulldowns to the CC pins (normally its ~5.1k, but maybe 10k would work?) but I also cant promise you that will work either.

I do not mind, but ATM I do not have any USBC-breakout boards. I plan to purchase some along with a logic-analyzer. If I get the items I will post and ask for pointers.

Another thing to try would be to log the PD messages when you boot the TS80P into DFU, as, as far as I know the DFU runtime wont touch the FUSB302 and thus it should act as a "dumb" PD device. This should cause the power supply to spam the source capabilities message for at least a few seconds.... should.

For now I was unable to boot into DFU with this charger. I need to test this in more detail and create another table.

USB A->C cables can never use PD as they are missing the required connections. QC may still work, but its a bit of a nightmare standard so I recommend avoiding it where you can :)

Yeah, I know, believe me. worngly wired cables, wrong resistors, too long. There are very few such cables that are made to specification. That is why I mentioned I am using USB-IF certified cable.
Anywayy: I wanted to check what the behavior is when only minimum pins are connected. I think I will also try to mask D+/D- pins and just leave GND + Vbus and see what happens.

TL;DR: will do more testing, prep another table with the meter connected

[remi-sc]

I think I will also try to mask D+/D- pins and just leave GND + Vbus and see what happens.

I checked and my intuition did not disappoint me - without D+/D- pins there is a configuration that works at 5V with TS80P connected directly to the EP-TA845.
I updated the table above.

Related exerpt:

C-C cable	E-marker chip?	plug positions	works on EP-TA845?	symptoms on EP-TA845	works on stock charger?	EP-TA845 works with Lenovo 4X90U45346 PD trigger?
Amazonbasics B01GGKYR2O 3.1 A-C cable + A>C 4pin adapter (no CC pin)	no	4 positions with A>C adapter on the TS80p	no	blank screen	no (blank screen)	no
Amazonbasics B01GGKYR2O 3.1 A-C cable + A>C 4pin adapter (no CC pin)	no	4 positions with A>C adapter on the charger	no	boots past miniware logo, displays programmed custom logo, goes blank	yes (9v)	no
Amazonbasics B01GGKYR2O 3.1 A-C cable + A>C 4pin adapter (no CC, D+/D- pins masked	no	4 positions with A>C adapter on the TS80p	no	blank screen	no (blank screen)	no
Amazonbasics B01GGKYR2O 3.1 A-C cable + A>C 4pin adapter (no CC, D+/D- pins masked	no	4 positions with A>C adapter on the charger	YES	stays at 5V	yes (5v)	no

[remi-sc]

Summary of tests trying to boot into DFU mode by connecting TS80P to a charger directly:

C-C cable	E-marker chip?	plug positions	DFU works on EP-TA845?	symptoms on EP-TA845	DFU works on stock charger?
stock	no	All 8	no	blank screen	yes
Accura ACC2177	no	All 8	no	blank screen	yes
Unitek C14059BK	yes	All 8	no	rapid miniware logo flashing	yes
unknown	yes	All 8	no	rapid miniware logo flashing	yes
Amazonbasics B01GGKYR2O 3.1 A-C cable + A>C 4pin adapter (no CC pin)	no	4 positions with A>C adapter on the TS80p	no	blank screen	no
Amazonbasics B01GGKYR2O 3.1 A-C cable + A>C 4pin adapter (no CC pin)	no	4 positions with A>C adapter on the charger	yes but not always	either boots DFU correctly or flashes miniware logo and goes blank	yes
Amazonbasics B01GGKYR2O 3.1 A-C cable + A>C 4pin adapter (no CC, D+/D- pins masked)	no	4 positions with A>C adapter on the TS80p	no	blank screen	no
Amazonbasics B01GGKYR2O 3.1 A-C cable + A>C 4pin adapter (no CC, D+/D- pins masked)	no	4 positions with A>C adapter on the charger	yes	boots DFU correctly	yes

I should be able to post similar info about "TS80<cable>USB meter<cable>charger" setups tomorrow

[Ralim]

Hi,

So the final tests you did with the masking on the USB pins is interesting.
I'm wondering if this charger does not ignore the USB data pins but is instead expecting something, and when it sees anything else its tripping off and resetting?

Have you tried triggering QC on this from a tester perhaps?

Otherwise I'm afraid this might be one for the "cant support" list 😢

That said, always happy to keep trying things, but really its getting to thin ice if it wont boot dfu consistently

[remi-sc]

I'm wondering if this charger does not ignore the USB data pins but is instead expecting something, and when it sees anything else its tripping off and resetting?

I rather think it's quite opposite - the TS80P is probably sending something that makes the charger do a reset.
The charger works with lenovo PD trigger, it charges my Xperia phone and a Dremel. It seems to work well enough on other products.

Have you tried triggering QC on this from a tester perhaps?

Yes, i tried all available triggers:
QC2 : doesn't work
QC3 : doesn't work
Apple 2.4A : seems to work (although it's only 5V)
PD : Works fully
Huawei FCP/SCP/SSCP : doesn't work
VOOC/DASH/WARP CV and super VOOC freeze/crash the meter

None of those triggers reset the charger in a similar way like with TS80P

Otherwise I'm afraid this might be one for the "cant support" list cry
That said, always happy to keep trying things, but really its getting to thin ice if it wont boot dfu consistently

Yes, the moment it became apparent that DFU mode doesn't work and that IronOS doesn't even have a chance to boot it became fairly clear this is beyond the IronOS code and the issue lies lower in the stack.

But the problem with power cycling seems wide-spread by looking at this whole thread.
I don't really care for supporting this specific Samsung charger but if it doesn't work then how to decide what to purchase?

What I would like to know is the reason behind those issues and maybe a way to determine which products would be compatible. I know the tests I do most likely won't help fix the issue but I hope they may bring better chance for informed purchase decisions.

---

Tangent about a struggle trying to find a charger to buy:

The thing you speculated upon:

Now, given this is a Samsung charger that they clearly dont market as a general USB PD charger, its quite possible its not certified and may have issues in certain cases. There are lots out there that have issues in their PD implementation.

I checked and It actually is a USB-IF sanctioned product: https://usb.org/single-product/3109 (Samsung may have simply chosen to skip USB-IF logo for branding reasons)

Now: USB-IF certification is not infallible. I know, but I'd like to think it's a good indicator.

PD specification does not require 12V output so to get it from a PD charger I think it needs to support 15V or 20V PPS
So if I look at the products listed on https://usb.org/products and look for 15V/20V programmable output "power brick" with a caveat of a desire to also charge my laptop (min 45W) and for it to not have an integrated cable I have very little choise and the samsung EP-TA45 looks like a no-brainer with it being relatively cheap, good brand and widely available.

Question to you @Ralim : what PD charger are you using ATM?

[remi-sc]

Documenting the behavior when using a "charger<cable A>meter<cable B>TS80P" setup will take a bit longer than anticipated.
I spent good few hours changing cables and filling out a spreadsheet and it is a complete mess with A_LOT of unexpected things happening depending on the cable position, cable type or even the order of connecting those cables. I see resets, slower resets, successful 12v, flat 0v or 5v at a start which jumps to 9V after boot.

Things I can confirm for now:

1. If the PD-tester meter switch is "off" then the meter seems to simply act as a cable with builtin volt/amp meter. (with a caveat of point 3)
2. If the PD-tester meter switch is "on" then the meter is somehow keeping the connection alive and that in some cable positions allows to negotiate 12V. I can then disconnect the TS80P and the charger will still keep outputting 12V. Only after disconnecting the meter from the charger the voltage drops.
3. I found that if "cable B" is connected first then only one position of "cable A" will supply basic 5V when connected, another will always result in 0v - on stock and samsung charger alike. This is regardless of PD-tester switch position. (So I guess this is an annoying quirk of this CT-2 meter)

Because of the point 3 I need to redo most of the tests involving the meter. (Previously posted direct Charger<cable>TS80P tests are still valid to the best of my knowledge)

[remi-sc]

Results with a meter below. Nothing helpful unfortunetely.
With PD message logging enabled (distinct from the PD-tester switch from the table) I was unable to capture any new behaviors on EP845 - either nothing or endless SOP messages while resetting.

1st c-c cable (charger – meter)	2nd c-c cable (meter – TS80P)	PD tester switch enabled	EP845	Stock TS80P charger
Stock TS80P cable	Accura ACC2177	no	Keeps resetting or stays at 0v	12v right away or stays at 0v
	Unitek C14059BK
	Unknown 20V/5A cable
Accura ACC2177	Stock TS80P cable
	Unitek C14059BK
	Unknown 20V/5A cable
Unitek C14059BK	Stock TS80P cable
	Accura ACC2177
	Unknown 20V/5A cable		Resets or resets **slowly** or stays at 0v
Unknown 20V/5A cable	Stock TS80P cable		Keeps resetting or stays at 0v
	Accura ACC2177
	Unitek C14059BK		Resets or resets **slowly** or stays at 0v
Stock TS80P cable	Accura ACC2177	yes	12v right away or keeps resetting	12v right away or starts at 5v and negotiates 9v after boot completion
	Unitek C14059BK
	Unknown 20V/5A cable
Accura ACC2177	Stock TS80P cable
	Unitek C14059BK
	Unknown 20V/5A cable
Unitek C14059BK	Stock TS80P cable
	Accura ACC2177
	Unknown 20V/5A cable		12v right away or keeps resetting **slowly**
Unknown 20V/5A cable	Stock TS80P cable		12v right away or keeps resetting
	Accura ACC2177
	Unitek C14059BK		12v right away or keeps resetting **slowly**

Few further notes:

1. When 12v is negotiated (in all cases in the table) it happens pretty much right away - before even a custom logo appears. After connecting the cable I first see 5v for about few hundred ms and then it goes up to 12v. Can it be that this happens before IronOS kicks in?
2. When 9V is negotiated (in all cases in the table) it happens after boot completes. It starts at 5, boots past custom logo into the main menu and after 1-2 seconds it jumps to 9v
3. Slow resetting mentioned in the table happens only if both cables have e-mark chips

[remi-sc]

I finally got the breakout boards and I can confirm that removing D+ and D- pins allows the TS80P to negotiate 12V with EP845 while it was rebooting with them:

The passthrough breakout adapter:

From the side you can see 2 pins are not connected:

Parts:

From this I can only assume that the TS80P is transmitting something over the D+/D- during early boot that makes the Samsung charger restart - presumably QC (EP845 does not support it)

It is possible that other chargers mentioned in this thread behave in a similar way - afaik Apple charger is also a non-QC charger.

Also:
I got myself a different charger: Baseus GaN2 Lite 65W - it supports both QC and PD - it works without issues

[Ralim]

Gah that is very annoying.

Had a bit of a poke around and it looks like the bootloader tries to establish usb comms (or at least does a bit of io toggling) that im guessing the charger doesnt like.

Sorry that in the end not much could be done to help with this charger for you :(

[discip]

@sdaitzman
Is this issue still present with the latest release?
Otherwise please close this issue. 😊

Obviously this is a charger related issue and it definitely goes beyond the scope of IronOS to support every imaginable charger out there.

thanks

[toabi]

Just noticed the same issue with my new TS80P. For anybody else finding this: I then plugged it into the macbook (instead of direct USB-C -> USB-C) with a USB-C to USB-A adapter and a USB-A to USB-C Cable and it works :D