Ralim
TS101 (V2.23 RC3) permanently reboots with Anker 735 PD-Charger (GaNPrime 65W)
Describe the bug I have flashed the firmware V2.23 RC3 on my Miniware TS101. If I connect the TS101 to a regular (low power) USB-C source, it runs without issues. However, if I connect it to my PD-Charger of type "Anker 735 Charger (GaNPrime 65W)" the TS101 permanently reboots.
To Reproduce
- Connect the TS101 to an Anker 735 Charger (GaNPrime 65W)
Expected behavior The TS101 should run stable without reboots.
Details of your device:
- Device: Miniware TS101
- Release:
- Power adapter being used: Anker 735 (Link)
Additional context
Anker chargers have had other issues before.
To confirm, is this issue present with 2.22 as well?
Just to add to the context: Mine 101 does reboot on an anker 140w power bank as well. On the PD debug menu it reboots right after the state 6. on the 2.22 stable it negotiates like a charm on PD at 28v.
Anker chargers have had other issues before. The original Miniware TS101 firmware (not IronOS) worked fine for month with the Anker charger.
To confirm, is this issue present with 2.22 as well? 2.22 works fine without reboots.
I have the same issue with my Samsung 65W charger EP-T6530, the TS101 will keep rebooting and the voltage display on the TS101 reads 5V.
My Software Version is v2.23E.DD4A5500.
In DFU it's stable.
Sometimes it manages to work, it will read 21V, but I don't know how to do that.
The same applies when using different chargers and power banks. Everything works on firmware 2.22.
My Pinecil v2 also keeps rebboting with at least 3 different kind of chargers. One of my chargers has a voltage display. I notice that the voltage during boot keeps dropping below 5V. However when I press the - button on the pincil just in time while booting, it seems that the heating is is delayed just enough to get the charger going.
FYI, I've rebuilt v2.22 locally using gcc version 13.2.1 20231009 (Arm GNU Toolchain 13.2.rel1 (Build arm-13.7)), the bug is present. But not with the hex file in the release on github
FYI, I've rebuilt v2.22 locally using
gcc version 13.2.1 20231009 (Arm GNU Toolchain 13.2.rel1 (Build arm-13.7)), the bug is present. But not with the hex file in the release on github
This observation sounds very interesting. Has anyine an idea what could go wrong during the build?
And FYI, when using the docker image from v2.22 (based on alpine 3.16), I can successfully build v2.23-rc4 and the bug is not present!
I have a ts101 and wanted to see if I could help. I Cloned the repository and setup msys2 in windows. When I compiled v2.22 I had the same PD negotiation boot loop as v2.23-rc4 which is strange because if I download v2.22 from github it works as expected. Then i setup docker to see if it was a tool chain issue and v2.22 compiled and could use 20v with USB PD. Next I compiled v2.23-rc4 in docker and that also worked with 20v USB PD.
So my USB PD boot loop is fixed by using firmware compiled in docker. I have attached a working copy of v2.23-rc4 in english compiled in docker.
I have a ts101 and wanted to see if I could help. I Cloned the repository and setup msys2 in windows. When I compiled v2.22 I had the same PD negotiation boot loop as v2.23-rc4 which is strange because if I download v2.22 from github it works as expected. Then i setup docker to see if it was a tool chain issue and v2.22 compiled and could use 20v with USB PD. Next I compiled v2.23-rc4 in docker and that also worked with 20v USB PD.
So my USB PD boot loop is fixed by using firmware compiled in docker. I have attached a working copy of v2.23-rc4 in english compiled in docker.
Your firmware file actually fixed the problem with 1 of my chargers, but the QC3.0 comes with the iron still bootloops
I have a ts101 and wanted to see if I could help. I Cloned the repository and setup msys2 in windows. When I compiled v2.22 I had the same PD negotiation boot loop as v2.23-rc4 which is strange because if I download v2.22 from github it works as expected. Then i setup docker to see if it was a tool chain issue and v2.22 compiled and could use 20v with USB PD. Next I compiled v2.23-rc4 in docker and that also worked with 20v USB PD.
So my USB PD boot loop is fixed by using firmware compiled in docker. I have attached a working copy of v2.23-rc4 in english compiled in docker.
Thank you for this, it seems to work great with my iron and my 28v supply. On the stock firmware I ran in to constant issues negotiating 28v over PD.
This is just a straight compile of the firmware, right? You don't have any modifications other than running it on Docker?
This is just a straight compile of the firmware, right? You don't have any modifications other than running it on Docker?
no modification. i was making sure i had everything setup to compile correctly and uploaded it to my iron as a test
Had exactly the same issue on Rocoren S-TR-267. This fixed it.
I have a ts101 and wanted to see if I could help. I Cloned the repository and setup msys2 in windows. When I compiled v2.22 I had the same PD negotiation boot loop as v2.23-rc4 which is strange because if I download v2.22 from github it works as expected. Then i setup docker to see if it was a tool chain issue and v2.22 compiled and could use 20v with USB PD. Next I compiled v2.23-rc4 in docker and that also worked with 20v USB PD.
So my USB PD boot loop is fixed by using firmware compiled in docker. I have attached a working copy of v2.23-rc4 in english compiled in docker.
@Ralim Would you mind having a look at this Sir? 😊
Not really sure what to make of this. Only difference I can see at a guestimate is that the firmware was linked in a different order.
As the clone chips use slow flash (and a cache to hide the speed), I'm guesssssing that there is a timing issue here at runtime, where the order of the code being linked (i.e. the chunks assembled to the final binary) matter.
Most likely fix would be to reduce the latency elsewhere in the handling in the USB-PD messages. I have been messing with a refactor to USB-PD that will probably help with this. Though I want to do regression test & release of 2.23 first when I get some time to work through all the devices.
@joe-scotto I would be curious exactly how it was build, in terms of commands used and machine it was built on. Just incase building in-order (no -j $(nproc) ) makes this workaround repeatable
Not really sure what to make of this. Only difference I can see at a guestimate is that the firmware was linked in a different order.
As the clone chips use slow flash (and a cache to hide the speed), I'm guesssssing that there is a timing issue here at runtime, where the order of the code being linked (i.e. the chunks assembled to the final binary) matter.
Most likely fix would be to reduce the latency elsewhere in the handling in the USB-PD messages. I have been messing with a refactor to USB-PD that will probably help with this. Though I want to do regression test & release of 2.23 first when I get some time to work through all the devices.
@joe-scotto I would be curious exactly how it was build, in terms of commands used and machine it was built on. Just incase building in-order (no
-j $(nproc)) makes this workaround repeatable
I'm pretty sure i know why he could build it working succesfully, cause he used the cached docker container if you don't delete it, it uses the old one from v2.22 to build it. Cause im lazy here is an AI Summary of what i found. I used Cursor to go through git bisect so i didn't have to do it myself. Attached is the for me working v2.23 final.
edit: if its any relevant is build this on Ubuntu Desktop with Docker 28.4.0
Root Cause Found: Compiler Update Breaking PD Negotiation
I experienced the same issue with my TS101 and modern PD power banks (INIU 140W 22.5V, Anker 735 GaNPrime). The device would boot-loop repeatedly when connected to these power banks, while v2.22 worked perfectly.
Investigation Results
Using git bisect between v2.22 (working) and v2.23-rc1 (broken), I identified the problematic commit:
849d1f7d - "Update compilers (#1858)" (Dec 26, 2023)
This commit updated the Docker build environment from Alpine 3.16 → Alpine 3.19, which includes a newer GCC version. The newer compiler appears to optimize the time-critical PD negotiation code too aggressively, causing timing issues with modern PD 3.1 power banks.
Workaround / Fix
Revert the Dockerfile to the version before the compiler update:
cd ~/IronOS-v2.23
git show 849d1f7d^:scripts/IronOS.Dockerfile > scripts/IronOS.Dockerfile
Then rebuild with --no-cache:
docker compose -f Env.yml build --no-cache
docker compose -f Env.yml run --rm builder bash -c "cd source && make -j\$(nproc) model=TS101 firmware-DE"
Result: v2.23 with full display support AND working PD negotiation! ✅
Affected Hardware
- TS101
- Modern PD 3.1 power banks
Possible Long-Term Solutions
- Identify which specific compiler optimization flag causes the issue
- Add
-fno-aggressive-loop-optimizationsor similar to timing-critical code - Mark critical PD/I2C functions as
__attribute__((optimize("O1")))to prevent over-optimization - Update Alpine 3.19+ compiler flags to match 3.16 behavior for embedded targets
Hope this helps fixing the issue!
Hi, I wanted to spend some time investigating the issue, and to ease flashing I started by switching from miniware's bootloader (DFU:1.05) to IronOS-dfu v0.4.
And to my surprise, when using this bootloader, the v2.23 firmware no longer reboots when negotiating USB PD 🤷
And I even restored the miniware bootloader to confirm the issue reappears in this case.