Add support of OLED screen for TS101 (new HW revision of display/PCB?)

[showier-drastic]

Describe the bug

After flashing 2.23-RC1 on a newly-purchased TS101, the display is not working properly.

To Reproduce

1. Flash the firmware on it

Expected behavior
Displays correctly

output.mp4

Details of your device:

• Device: TS101
• Release: 2.23-RC1
• Power adapter being used: Irrelevant, issue exists regardless of adapter
• If this is an accelerometer related issue, please include its model number here:

Additional context

[ia]

After flashing 2.23-RC1 on a newly-purchased TS101, the display is not working properly.

Could you, please, honestly remember: did you use the device with the original Miniware firmware before flashing IronOS?

Power adapter being used: Irrelevant, issue exists regardless of adapter

No, it's not irrelevant. Let this decide to people who may have time & knowledge to help without telepathic skills. ;)

Although some details during report may seem insignificant, for any good bug report the more information you provide, the better (even if it won't be needed in the end).

So... could you tell, please, what power adapter did you use exactly right before it happened? Did you attach power cable over DC barrel connector or over USB-C port?

[showier-drastic]

@ia Thanks for the tips.

After flashing 2.23-RC1 on a newly-purchased TS101, the display is not working properly.

Could you, please, honestly remember: did you use the device with the original Miniware firmware before flashing IronOS?

Yes, and the original firmware works normally. I think this might indicate some hardware revision that changes the screen model?

Power adapter being used: Irrelevant, issue exists regardless of adapter

No, it's not irrelevant. Let this decide to people who may have time & knowledge to help without telepathic skills. ;)

Although some details during report may seem insignificant, for any good bug report the more information you provide, the better (even if it won't be needed in the end).

So... could you tell, please, what power adapter did you use exactly right before it happened? Did you attach power cable over DC barrel connector or over USB-C port?

I've tried all possible options (DC connector, dumb 5V USB-A to USB-C, and 30W Apple Adapter that comes with my MacBook), and they all have the same issue. Therefore I say that it's irrelevant. Also it happens right after I flashed the firmware, so the adapter I'm using right before it happened is my MacBook Pro 2021.

[ia]

I've tried all possible options (DC connector

I had to ask, because recently there was a very similar comment. Here is the statement that it did happen only because of unlucky power source through DC barrel. I thought it may be related.

Also it happens right after I flashed the firmware

Could you try to flash the original firmware back? Even if screen doesn't work, if it's only OLED issue with IronOS, then you could try go to DFU mode and flash the Miniware firmware to see if the screen works again.

[oliverpool]

I also purchased a TS101 recently (edit: actually Aug 2024, so not soooo recent).
The stock firmware worked fine (forgot to write down the version), DFU indicates 1.05.

I upgraded first to v2.22 without problems (the display was small, as expected).
Then I upgraded to v2.23-rc1 without problem (display is now fullscreen), when connected to my computer (05) or to a proper USB adapter (21).

(it does not likely help the OP, since everything seems to work fine for me - in my case only a big "thank you" to the maintainers for the great work!)

[showier-drastic]

@ia Sorry for the late reply.

Just flashed back to original firmware (TS101AppV210.zip). It works without issue, no display corruptions. All function works properly.

[ia]

Just flashed back to original firmware (TS101AppV210.zip). It works without issue, no display corruptions. All function works properly.

So we just eliminated the theory about OLED corruption by bad power source, in your case. I'm sincerely happy to know that physically your screen works and that it hasn't been damaged.

Now, could you, please, try the stable release of v2.22 build on your TS101 and report results back? Thanks.

[showier-drastic]

It is still corrupted with v2.22.

output.mp4

[oliverpool]

Stupid question: which file did you put on the device? (language and extension)

[showier-drastic]

Stupid question: which file did you put on the device? (language and extension)

TS101_EN.hex

[oliverpool]

ts101_en.hex sounds good.

When flashing, what is displayed as DFU version?
You get the .rdy file after flashing, right?
(sorry if those questions sound stupid, but I am looking to find any visible difference between our devices)

[showier-drastic]

ts101_en.hex sounds good.

When flashing, what is displayed as DFU version?

DFU:1.06

You get the .rdy file after flashing, right?

Yes.

(sorry if those questions sound stupid, but I am looking to find any visible difference between our devices)

No these are not stupid questions; I appreciate your help very much.

[ia]

@Ralim, could you look at this when you have time, please?

I think this might indicate some hardware revision that changes the screen model?

Probably this is the most reasonable assumption so far: it seems Miniware did start to change OLED screen model in TS101, so hardware-related code to control the screen doesn't work properly anymore.

And, @Ralim, is there any way to get OLED model like we do it with accelerometers, for example?

@showier-drastic, I'm not familiar with a hardware construction & case of TS101, but, at your own risk, you could very carefully disassemble your TS101 to see if there is any ID on or around OLED screen (to get the exact model). Another suggestion (a bit crazy though) - you could play a social engineering card a bit: write to Miniware official support email/contact, tell them that you damaged OLED, but you did replace it yourself by re-soldering, but now it doesn't work (you could attach photo that you showed us here) and ask them something like: "could you, tell me, please, which OLED screen exactly (manufacturer/model/id) I should buy to replace it successfully?" (believe it or not, but Miniware is very unfriendly about sharing any information about their devices & hardware willingfully).

[showier-drastic]

@Ralim, could you look at this when you have time, please?

I think this might indicate some hardware revision that changes the screen model?

Probably this is the most reasonable assumption so far: it seems Miniware did start to change OLED screen model in TS101, so hardware-related code to control the screen doesn't work properly anymore.

Is it possible that we can try some code with similar OLED models? I'm willing to collaborate on trying to flash and debug.

And, @Ralim, is there any way to get OLED model like we do it with accelerometers, for example?

@showier-drastic, I'm not familiar with a hardware construction & case of TS101, but, at your own risk, you could very carefully disassemble your TS101 to see if there is any ID on or around OLED screen (to get the exact model). Another suggestion (a bit crazy though) - you could play a social engineering card a bit: write to Miniware official support email/contact, tell them that you damaged OLED, but you did replace it yourself by re-soldering, but now it doesn't work (you could attach photo that you showed us here) and ask them something like: "could you, tell me, please, which OLED screen exactly (manufacturer/model/id) I should buy to replace it successfully?" (believe it or not, but Miniware is very unfriendly about sharing any information about their devices & hardware willingfully).

Unfortunately it seems that it's impossible to see the screen model without doing damage to the iron: https://www.ifixit.com/Guide/Disassembling+Miniware+TS101+soldering+iron/169989

Maybe I can try some social engineering as you mentioned, let's see if that works out.

[showier-drastic]

Here's an internal picture of the iron, in case that helps:

[ia]

Unfortunately it seems that it's impossible to see the screen model without doing damage to the iron: https://www.ifixit.com/Guide/Disassembling+Miniware+TS101+soldering+iron/169989

But what about this TS101 disassemble howto? It looks "less damaging" as far as I understand, and as the title says. Sorry, I'm shooting in the dark here, since I don't own TS101 myself, but still trying to help with everything I can.

Oh, and another question: where did you get your TS101? Is there at least smallest chance that it may be some kind of clone, but not originally produced by Miniware?

[showier-drastic]

Unfortunately it seems that it's impossible to see the screen model without doing damage to the iron: https://www.ifixit.com/Guide/Disassembling+Miniware+TS101+soldering+iron/169989

But what about this TS101 disassemble howto? It looks "less damaging" as far as I understand, and as the title says. Sorry, I'm shooting in the dark here, since I don't own TS101 myself, but still trying to help with everything I can.

Thanks for this, but I do not feel that I can remove the glass without breaking it, so unless it's absolutely necessary, I prefer not to try this way.

To me the screen issue sounds like it might be resolved by tweaking OLED registers, I will probably try to debug the firmware when I have some time.

Oh, and another question: where did you get your TS101? Is there at least smallest chance that it may be some kind of clone, but not originally produced by Miniware?

On a taobao shop (购百应科技). It seems to have a high sales volume.

[ia]

I do not feel that I can remove the glass without breaking it, so unless it's absolutely necessary, I prefer not to try this way.

No problem, thanks for checking out anyway.

it might be resolved by tweaking OLED registers

Yeah, as far as I understand, this is the exact root cause - if they changed hardware revision of OLED model, then the calls to support new model should be added as well. However, without knowing the exact model and its datasheet, there is not so much we can do, I guess. :(

Oh, I have another theory: they could keep the same OLED model, but may change PCB design a bit with modification to traces between, let's say, MCU and OLED, so in this case a new pinout "map" could be a good start. Visual inspection (even with cheapest usb microscope) and multimeter (in signal tracing mode with very thin probes) are the best friends here (take-out of the main PCB from the main shell is still required though, and there is no any guarantee that even that will help right away, so just leaving this advice for the bravest ones).

Another question! If you have opportunity and mood to keep experiments with (re-)flashing, or maybe you have this information from the previous run of IronOS on your device: even without OLED displaying info properly, did you notice that IronOS works in general, anyway? I.e., if you flash IronOS, and on the first power-on you press +/A button to go to Soldering Mode & moving the tip to the solder, does the tip melt the solder? And does the tip cool off after long -/B press? Just use measures of precaution, please, since there is no any feedback from the screen, if you decide to check.

On a taobao shop (购百应科技). It seems to have a high sales volume.

Just one more thing on that - what was the exact date of you placing the order? And date of you receiving your TS101? This may help, if we will start to receive the similar reports soon.

P.S. Thank you for keeping in touch, it's a rare thing around here in the issue tracker. But if you don't mind, I would like to update the title since we established this as the fact that luckily your OLED is not corrupted. :)

[showier-drastic]

Oh, I have another theory: they could keep the same OLED model, but may change PCB design a bit with modification to traces between, let's say, MCU and OLED, so in this case a new pinout "map" could be a good start. Visual inspection (even with cheapest usb microscope) and multimeter (in signal tracing mode with very thin probes) are the best friends here (take-out of the main PCB from the main shell is still required though, and there is no any guarantee that even that will help right away, so just leaving this advice for the bravest ones).

A quick find is that the PCB revision number of mine and whitequarks' (in your disassemble guide) are the same (V1.51A). So the possibility of this should be somewhat low.

Another question! If you have opportunity and mood to keep experiments with (re-)flashing, or maybe you have this information from the previous run of IronOS on your device: even without OLED displaying info properly, did you notice that IronOS works in general, anyway? I.e., if you flash IronOS, and on the first power-on you press +/A button to go to Soldering Mode & moving the tip to the solder, does the tip melt the solder? And does the tip cool off after long -/B press? Just use measures of precaution, please, since there is no any feedback from the screen, if you decide to check.

On a taobao shop (购百应科技). It seems to have a high sales volume.

Just one more thing on that - what was the exact date of you placing the order? And date of you receiving your TS101? This may help, if we will start to receive the similar reports soon.

Roughly 3 weeks ago.

P.S. Thank you for keeping in touch, it's a rare thing around here in the issue tracker. But if you don't mind, I would like to update the title since we established this as the fact that luckily your OLED is not corrupted. :)

Thanks for your help too. It's very important to get in touch.

[showier-drastic]

The rest of IronOS's functionality seems to be working. If I press the + button, the tip heats up, and I can tell that the temperature numbers are changing from the corrupted image. If I press the - button, some animation happens. Screen rotation works too, as shown in my video.

[ia]

A quick find is that the PCB revision number of mine and whitequarks' (in your disassemble guide) are the same (V1.51A).

Good catch. Didn't pay attention to this myself.

So the possibility of this should be somewhat low.

Yes... unless they did it without renaming the version on the PCB. Not sure how much this probable though. :/

It's very important to get in touch.

Although at this point I don't have much to comment/provide anymore, unfortunately. :(

[Ralim]

Hia,

This definitely screams of a bad OLED init sequence.
Are you able to build IronOS yourself?

It's most likely one of these :

IronOS/source/Core/Drivers/OLED.cpp

Line 36 in 4ce63fa

I2C_CLASS::I2C_REG OLED_Setup_Array[] = {

I would be suspect its lines 39-42 (inclusive); as those do change with different clones of the OLED's.

If your able to build locally, changing those +-1 to see results can often be telling?

[resistancelion]

I had to ask, because recently there was a very similar comment. Here is the statement that it did happen only because of unlucky power source through DC barrel. I thought it may be related.

Yeah, but that was due to constant voltage fluctuation (got a PSU that trades voltage for amps, not the opposite as it should...)

Just flashed back to original firmware (TS101AppV210.zip). It works without issue, no display corruptions. All function works properly.

So we just eliminated the theory about OLED corruption by bad power source, in your case. I'm sincerely happy to know that physically your screen works and that it hasn't been damaged.

Now, could you, please, try the stable release of v2.22 build on your TS101 and report results back? Thanks.

This thing with PSU and voltage spikes provokes only converter part of the circuit to fail, in my case it was the same capacitor and transistor over and over again, i have no idea why something else didn't fail on PCB, but ok

[oliverpool]

In the meantime, maybe an hint could be added to the README in the "Miniware TS101" notes, linking to this issue:

OLED issues with DFU:1.06

[XaocuHKa]

got ts101 from Amazon US yesterday, same issue as OP. rollback to OG FW resolves the issue.

[showier-drastic]

Just to add a note here, when I am trying to debug my TS101 with SWD today (I want to extract the correct OLED sequence by reverse-engineer their DFU firmware), I found that the MCU is secured, so the DFU firmware cannot be read out. Obviously they do not want us to read it... It should still be possible, though, through a modified App, but will be much more difficult to do. Sad.

[showier-drastic]

Based on some experiments, I think the main difference of the new unknown OLED model and the good-old SSD1307 are the following:

• Some offset difference (so that the current initialization code needs some tweaks that I'm unable to figure out)
• Most importantly, the new unknown OLED model does not support "Horizontal addressing mode" (register 20h => A[1:0]=00b) that we use now. After transmission of one page, it always goes back to the same page, instead of going to the next page. So we cannot send the whole screen at once. Frame buffer need to be sent page-by-page.

I did some reverse-engineering of the official App V210. The official App does not initialize the OLED screen at all; it relies on the bootloader to set up the screen. In the app, it just directly writes data to the OLED.

Based on the philosophy of doing things in the same way as the official firmware, I created a dirty experimental version (functions such as screen rotation won't work for now):

https://github.com/showier-drastic/IronOS/tree/oled-experiment-ts101

TS101_EN-2.hex.zip

The main changes are:

1. Remove anything related to the OLED reset pin (PA7)
2. Removed OLED init code
3. Rewrote the refresh method, based on function 0x0800db54 (I named it oled_bulk_write in my code) in official App.
4. Temporarily removed other places that touches the OLED config.

Please test if this works on your TS101 (especially with the "old" OLED model). If it works both on the old and new version, I think we can continue to see how to improve it, and finally integrate to the main code base.

[showier-drastic]

Just a humble request here that someone can test my firmware build, and if it works on older TS101, I will try to optimize the code quality.

[paulfertser]

It's great progress indeed, thank you for sharing!

My personal opinion though is that IronOS should rather not depend on hardware state inherited from bootloader, especially when it's miniware trash code.

[XaocuHKa]

Hey, thanks a lot for your help!

I have an issue after installing you FW branch on the new OLED, has some artifacts on the right side of the screen. Is that normal>

Luckily I have an old TS101 with broken heating element, so I can test the screen, but not heating. So, just installed your FW and it gets stuck in "calibrating". In PD Debug mode it says State 3 No VBus. Not sure if that helps.
Please let me know if there is anything I can do to test it further?

[showier-drastic]

Hey, thanks a lot for your help!

Thanks for your testing!

I have an issue after installing you FW branch on the new OLED, has some artifacts on the right side of the screen. Is that normal>

This is normal, as I did not implement the code related to the scrollbar area.

Luckily I have an old TS101 with broken heating element, so I can test the screen, but not heating. So, just installed your FW and it gets stuck in "calibrating". In PD Debug mode it says State 3 No VBus. Not sure if that helps. Please let me know if there is anything I can do to test it further?

Is the screen working? If yes, it might be unrelated to my change.

[showier-drastic]

It's great progress indeed, thank you for sharing!

My personal opinion though is that IronOS should rather not depend on hardware state inherited from bootloader, especially when it's miniware trash code.

I would say if we can get it to work, it does not matter much. Or we can keep two ways to initialize the screen? On old hardware we use the old way, on new hardware we use the new way. I'm not sure.

[paulfertser]

I would say if we can get it to work, it does not matter much.

Until someone finally adds support for proper DFU to https://github.com/Ralim/IronOS-dfu which should be actually quite easy and provide numerous advantages.

I do not have TS101 at hand for testing or else I'd just connected SWD and tried that...

Or we can keep two ways to initialize the screen? On old hardware we use the old way, on new hardware we use the new way. I'm not sure.

Not a clean solution IMHO; usually it's not too hard to find a suitable initialisation sequence for any display. I wonder if it really lacks any markings at all?

Again, not my call to judge here, I'm talking from a potential user point of view.

[oliverpool]

https://github.com/showier-drastic/IronOS/tree/oled-experiment-ts101

TS101_EN-2.hex.zip

I did flash this on my "older" device (DFU 1.05) and the screen looked good (didn't test heating).

(the 2nd line of the debug menu read 20250224)

[showier-drastic]

To @oliverpool and @XaocuHKa :

Thanks for testing! It seems that this approach works. I'll try to add all the missing functionality to my code to make it really usable.

To @paulfertser:

I would say if we can get it to work, it does not matter much.

Until someone finally adds support for proper DFU to https://github.com/Ralim/IronOS-dfu which should be actually quite easy and provide numerous advantages.

With, or without, the potential IronOS-dfu support, I would say it's okay to rely on the DFU to initialize the OLED.

I do not have TS101 at hand for testing or else I'd just connected SWD and tried that...

The device is locked. You cannot debug anything (even dumping the DFU firmware is impossible via SWD), until you erase the whole device, which I would prefer not to do right now.

Or we can keep two ways to initialize the screen? On old hardware we use the old way, on new hardware we use the new way. I'm not sure.

Not a clean solution IMHO; usually it's not too hard to find a suitable initialisation sequence for any display. I wonder if it really lacks any markings at all?

It will be possible to find the sequence via reverse engineering, if anyone can dump the DFU firmware. I'm happy to do the reverse-engineering of DFU (I've already reverse-engineered the App part, so it should be easy to do it again on DFU). Dumping the DFU firmware should be possible utilizing the USB device peripheral of the MCU, but I currently do not have time to write this dumping part.

Again, not my call to judge here, I'm talking from a potential user point of view.

Thanks for your comment!

[paulfertser]

It will be possible to find the sequence via reverse engineering, if anyone can dump the DFU firmware. I'm happy to do the reverse-engineering of DFU (I've already reverse-engineered the App part, so it should be easy to do it again on DFU). Dumping the DFU firmware should be possible utilizing the USB device peripheral of the MCU, but I currently do not have time to write this dumping part.

I think it's essentially already written in the form of that IronOS-DFU code, and it supports running from the offset normally used for "application", so it's safe to experiment with it by just uploading it via the vendor bootloader and trying to use for reading the flash out I guess. From a cursory look it seems like it's really a minimal modification needed to get it running on TS101, I just do not have a device for testing that. I do not feel like display init belongs to a bootloader, it might be probably better to have it than not but I do not see much value in doing it there either, hence my idea about IronOS display init being independent.

[Woodsnaps]

Very wild take, but! I think I might have found the issue:

When I used stock firmware (straight from the factory), I was able to change DisplayDir to Left. All worked fine. Then, I uploaded a new firmware via my macbook. After updating I seemed to get a black screen after the boot image. Very strange.
Then I tried reverting back to v1.11 and v2.01: issue persisted.
When changing the DisplayDir back to Right via the config file, the TS101 boots up normally. When changing back to "Left": issue returns.
Then I tried installing 2.23 IronOS and I get the exact same issue as @showier-drastic

Hypothesis: the macbook places the .Trashes, .fseventd and ._.Trashes on the Volume which are impossible to get rid of. Not via Windows, not via macOS.
Due to these files being present, the memory gets issues and can't initialize booting properly.

Can anyone confirm with a Windows PC (& having the TS101 never connected to macOS) that these files are not present?

-Edit: I also found another bug: when booting up normally with a working firmware, going to DisplayDir and changing it to "Left" without waiting 5 seconds to save, and then immediately go back to "Right", wait 5 seconds to save, causes the display to be mirrored and unreadable! Look at the attached photo:

[330Speedy]

Based on some experiments, I think the main difference of the new unknown OLED model and the good-old SSD1307 are the following:

• Some offset difference (so that the current initialization code needs some tweaks that I'm unable to figure out)
• Most importantly, the new unknown OLED model does not support "Horizontal addressing mode" (register 20h => A[1:0]=00b) that we use now. After transmission of one page, it always goes back to the same page, instead of going to the next page. So we cannot send the whole screen at once. Frame buffer need to be sent page-by-page.

I did some reverse-engineering of the official App V210. The official App does not initialize the OLED screen at all; it relies on the bootloader to set up the screen. In the app, it just directly writes data to the OLED.

Based on the philosophy of doing things in the same way as the official firmware, I created a dirty experimental version (functions such as screen rotation won't work for now):

https://github.com/showier-drastic/IronOS/tree/oled-experiment-ts101

TS101_EN-2.hex.zip

The main changes are:

1. Remove anything related to the OLED reset pin (PA7)
2. Removed OLED init code
3. Rewrote the refresh method, based on function 0x0800db54 (I named it oled_bulk_write in my code) in official App.
4. Temporarily removed other places that touches the OLED config.

Please test if this works on your TS101 (especially with the "old" OLED model). If it works both on the old and new version, I think we can continue to see how to improve it, and finally integrate to the main code base.

Based on some experiments, I think the main difference of the new unknown OLED model and the good-old SSD1307 are the following:

• Some offset difference (so that the current initialization code needs some tweaks that I'm unable to figure out)
• Most importantly, the new unknown OLED model does not support "Horizontal addressing mode" (register 20h => A[1:0]=00b) that we use now. After transmission of one page, it always goes back to the same page, instead of going to the next page. So we cannot send the whole screen at once. Frame buffer need to be sent page-by-page.

I did some reverse-engineering of the official App V210. The official App does not initialize the OLED screen at all; it relies on the bootloader to set up the screen. In the app, it just directly writes data to the OLED.

Based on the philosophy of doing things in the same way as the official firmware, I created a dirty experimental version (functions such as screen rotation won't work for now):

https://github.com/showier-drastic/IronOS/tree/oled-experiment-ts101

TS101_EN-2.hex.zip

The main changes are:

1. Remove anything related to the OLED reset pin (PA7)
2. Removed OLED init code
3. Rewrote the refresh method, based on function 0x0800db54 (I named it oled_bulk_write in my code) in official App.
4. Temporarily removed other places that touches the OLED config.

Please test if this works on your TS101 (especially with the "old" OLED model). If it works both on the old and new version, I think we can continue to see how to improve it, and finally integrate to the main code base.

Hi everyone.
This is perfect news!
I have exactly the same problem with my TS101 and this modified version TS101_EN-2.hex.zip solved the problem perfectly. But I have a huge question. Could someone help me compile exactly this firmware version, only in a different language version? (TS101_CS) I am not familiar with these completely unknown things like compiling firmware xD
Thank you all in advance for your help :)

[ttelford]

Based on the philosophy of doing things in the same way as the official firmware, I created a dirty experimental version (functions such as screen rotation won't work for now):

https://github.com/showier-drastic/IronOS/tree/oled-experiment-ts101

TS101_EN-2.hex.zip

I have an old(ish) TS101 purchased in late 2023: The OLED works! (It doesn't swap orientations, but I believe you mentioned it wouldn't/it wasn't a goal of the test).

[showier-drastic]

Thanks for all your testing! I'll probably find some time to integrate this method into the current code base. I'd like to do as this approach: use a macro to check whether it's TS101. if it is, then use the very minimal initialization code, and use "new way" to draw on screen; if it is not TS101, then use old code.

@ia @Ralim I'd like to hear about your opinion on the above; if it sounds OK, I'll start do it.

[Ralim]

I would vote against not initialising the display.

My logic here is that this will break things potentially when using other bootloaders if they don't initialise the display before the main firmware starts. And this can be a nightmare to debug for the user if they dont understand.

Additionally when I'm debugging issues on devices I normally dont run the bootloader (but just jump in directly with SWD debugger), so this would be annoying. Though I don't really support the TS101 so 🤷🏼.

I prefer to just reverse engineer the bootloader (I can send you this if you dont have it). As its more likely this means that we are missing a step (wrong oled reset pin? an enable pin?).

However having said that, I am ok with accepting this as a patch for now but I wouldn't want it to stick around forever if possible. Will likely need to add a note about support to the docs, and ensure that its clear that if miniware changes their bootloader in the future this may break and thats not in our space of control.

[MyHealthSheets]

Well, I just spent about the last 6hrs with what sounds like the same issue on a new TS101 I got earlier today :( . This thread looks like it came in pretty handy...

My device was working fine on the stock Miniware f/w, but of course having the device for a couple hours already, figured it was time to try out ironOS. After my first successful flash of IronOS, my OLED got scrambled. However, in my case, regardless of what f/w I tried flashing after (stock, ironOS v2.23rc4, v2.22 and even your recent patch), I couldn't get my OLED to display correctly.

I was about to give up, figured I could return my iron to Amazon, claim defective, but oddly I saw the comment a few above about macOS files getting added to the mounted 'TS101_DFU' drive. I honestly didn't think much of it, and still don't exactly see how these stupid auto MacOS files could cause any issues, but, I kinda think they did!?

While my DCU was mounted, I deleted to folders from my Terminal (rm -R) '.Trashes' and '.fseventsd'. After, I simply flashed the stock f/w again, and all of a sudden, my OLED was working! After, and without doing anything else, I quickly flashed the ironOS v2.23rc4, and my OLED was still working....

From there, I flashed a few more back and forth, and eventually my OLED get messed up again. I tested the theory and again deleted both folders from DCU mount, and after flashing both f/w's again, the OLED was working #shrug !?

Anyway, I think I can probably reproduce it again if you want any more info. Just as a heads up, as I was figuring out how to flash the f/w to begin with, I was going back and forth between a Ubuntu Server and my Macbook. It just happened that I was on my Mac when reading through this thread regarding the "extra" folders. I still don't quite get how they could have caused issues, I'd like to understand that better. It's really late for me right now, but perhaps I can take another look in the next couple days.

Thank you all though for this thread, as a Software Support Engineer by trade, this was nice to follow!