Pinecil V2, corrupted Snowy I2C screen using beta 2.19 firmware

[River-Mochi]

Describe the bug using 2.19 Beta for Pinecil V2, get snowy screen when V2 is left to idle in Debug mode. just flipping V2 brings it back to normal view, no need to unplug (sometimes need to press (-) button).
this is a minor issue, the V2 still works great and comes out of Sleep mode and snowy screen and goes back to normal screen easily when we flip it over or shake a little.

To Reproduce

• 2.18 , PD65W, and PD140W no snow, all is good: Debug mode, V2 goes stays normal display or black screen when Idle, picking it up display comes back on.
• 2.19, PD65W, or 140W charger Snowy corrupted screen while idling in Debug menu Tip R on screen (could be others but only had time to test those screens). this happens after leaving V2 to sit for several minutes untouched. Shaking/flipping V2 brings it back to normal display. sometimes shaking was not enough and I had to press (-) button to get back to a normal screen but reboot was not required. Sometimes there is corruption while on Main screen and using 2,19 and an EPR charger 140W. but Consistently 2.19 and Debug menu goes to noisy snow in Tip R or Uptime, and one other debug screen I tested.
• I also Swapped both V2 so one had 2.18 and one had 2.19. Swapping had the same results, 2.18 was good, 2.19 got corrupted screen when left to idle in Debug menu while looking at one of the settings.

Expected behavior

1. should behave like V1 did. no screen corruption while left to idle for 5-10- more minutes.
2. going to Black screen is desired, & Pick up brings screen back to life if done in xx amount of time.
3. should follow Shutdown rules, and shut down in time set in Sleep menu
4. technically V2 still works. if you flip it over it re-draws and a good screen comes back. this did not happen on V1 so people migrating from V1 to V2 might notice.

Details of your device: Test V1 to compare. Tested V2 on 2.18 stock and V2 on 2.19 beta (this happends on at least 2 versions of the beta since they are all numbered the same it tested on first 2.19 beta (correction of 0x00 padding), and last beta 3 days ago to (tweak 6.2ohm-8ohm trigger).

• Release: [2.19.6FAB3E5] beta
• Power adapter being used: PinePower desktop PD65W, Cirtek PD65w, Apple PD140W, Kovol PD140W.

See attachment, screen will either go Full Snow or half snow or partial snow on bottom.

[Ralim]

Can you please confirm if this occurs for you on : https://github.com/Ralim/IronOS/actions/runs/3120485217 What git hash is in your 2.18 stock firmware you are referring to? For the V2 it occurs on, what is the manufacturing date?

[River-Mochi]

2.18.A1A569A which was firmware.bin that Gamiee included with our tmp_flasher zip. of 10 tests with 3 different chargers, I did not get corruption on 2.18 but I just got corruption now using APPLE PD140 and EPR cable while in DEBUG menu. let me confirm a few more times.

[Ralim]

Just use an EPR charger for testing, no point testing across multiple. EPR puts most strain on I2C.

[River-Mochi]

ok ! it takes time to do these test because I have to let it sit for 5-10 min for result each test.

[River-Mochi]

I am only able to test 2.18 with the EPR Apple PD140W since it is only EPR I have that natively does not cause 2.18 to reboot.

[River-Mochi]

i just tested with 2.18.A1A569A , 2 runs. left it idle for 30 Min each run, on Debug, Time(uptime) view. it just stays on showing the time number increasing, no Snow corruption, no black screen, all good.

[Ralim]

For me I've had 2.20.0DDBE80 going for over an hour without any issues. 😓

[River-Mochi]

FYI ran 2.18 again on V2 for 58 min in debug mode, with no corruption

I will test Beta posted

[River-Mochi]

After 50 minutes on two V2, 2.20 beta, everything looks good no Snow or I2C corruption.

• I still see the Uptime display though it did not go to black screen. is this intentional it stays on?
• if it's idling for long time, it is desired it does Shutdown (black screen) per shutdown setting that is custom selected in sleep settings. my sleep shutdown is 5 min. but in Debug mode on Uptime for example, it stay on even though I did not touch the Iron for 50 minutes.
• If im on main screen then it goes to black screen shutdown correctly.

[Ralim]

Debug mode should not have the auto shutdown mode; so its expected the screen stays on, this is by design as the debug screen is for debugging issues, and not normally entered.

All other screens should have some form of shutdown though.

[VICLER]

I have the same issue on pinecil v2 with stock 2.18. I'm using PD 20V. After some idle time the screen is full of snow. Shacking does not help, only unplug. Where can I download a newer beta?

[ghost]

My 2.20 on EPR power is snowing. To trigger it it seems all I need to do it turn on detailed idle screen. At the idle screen, maybe 5 minutes after it goes black I gently wake it up with movement. I'll have a screen that looks like this https://drive.google.com/file/d/1-oxvlKp9NsFNCkr0zVFC3Uht2Ay0Lp06/view?usp=sharing It looks like it's writing random setting screens to the wait screen after the screen blanks out.

[River-Mochi]

My 2.20 on EPR power is snowing. To trigger it it seems all I need to do it turn on detailed idle screen. At the idle screen, maybe 5 minutes after it goes black I gently wake it up with movement. I'll have a screen that looks like this https://drive.google.com/file/d/1-oxvlKp9NsFNCkr0zVFC3Uht2Ay0Lp06/view?usp=sharing It looks like it's writing random setting screens to the wait screen after the screen blanks out.

Flux,

1. To ble clear turning on Detailed idle screen mode makes the snow happen? but if you are not in detaield screen you do not get snow?
2. what screen are you testing to idle or in? if it's just a couple images, I just drag & drop it directly in here, but if It's a lot I can see putting in separate document.
3. Does non- detailed idle screen mode in 2.20 help to have no snowy screen while idling?

[River-Mochi]

@Ralim I am also getting Snowy screen when I have V2 set to Detailed screen. it takes

I have the same issue on pinecil v2 with stock 2.18. I'm using PD 20V. After some idle time the screen is full of snow. Shacking does not help, only unplug. Where can I download a newer beta?

beta is in the post above.

[JoeyNinja]

Using Anker 140W EPR Battery. On 2.18: I've had snow appear on the main screen. On 2.19.FFD2C97: Main screen is fine, snow eventually appears on debug menu (tested on uptime screen). Have detailed idle enabled. On 2.20.0DDBE80: So far no snow anywhere. Have detailed idle enabled.

[River-Mochi]

Tested two different V2.

• V2-a is apple 140w.
• V2-b is Kovol 140w.

V2-a is detailed idle setting 2.20. main screen goes to black after a few minutes. When I pick it is slightly corrupted. Flipping it cleans & fixes display (photo).

V2-b 2.20 is normal no detailed settings. Main screen goes black as expected when I pick it up sometimes it looks good & sometimes it has strange words that I have no idea where they came from. This seems improved from more snowy screens. when it corrupts is grabbing words and charactors from other screens that are not the screen it is in. I went idle in Main screen, but It grabbed "interface" and added it to the screen.

[JoeyNinja]

Had a similar thing happen when idling on 2.20 non-detailed screen. Backwards letters for some reason.

[River-Mochi]

It seems better with 2.20 but if it can't be perfect, it does not seem to affect functionality, it just makes V2 look like it's broken. I lightly flip V2, then it refreshes the screen and everything is back to normal. All functions are good. I'm happy to live with this if it can't be fixed.

Potato suggested in the chat that maybe a real fix might need an extra Resistor or CAP on the PCB to help with EPR chargers stressing the I2C? for me this only happens if I leave it to Idle while I'm working and just pressing (-) button or gentle flip brings it back to normal. If it is affecting operation for anyone, then that is different.

[River-Mochi]

It's also not consistent, out of 5 tests now with 2.20 , my V2 that has normal view (no detailed) seems fine if I leave it idle sometimes ( it might be how long I leave it idle). Sometimes it will go black and I pick it up and it's normal, other times it goes black and I pick it up and half the main screen is corrupted or has strange words.

the other V2 with detailed screen enabled is more consistently having Snow every test but it's limited snow compared to 2.19 which was most of the screen.
This is only testing Main screen idle and not any debug menus.

[River-Mochi]

• 2.20 still has corruption.
• Had this happen during active soldering, not even idle.
• Using Kovol 140 charger & Epr cable.
• I was in soldering temp screen & soldering, noticed it switched to corrupt parts of "user interface" display.
• When it corrupts it likes to switch to parts of word "interface" or "user interface" screen even if I'm in soldering mode . This happened after only a few min of soldering.
• This happened on my one of my V2

[River-Mochi]

Different test using my Second V2 and not the same V2 that is in my last comment

• 2.20 all good using my 2nd V2 for last hour of soldering (it behaves very differently that the V2 posted above).
• did not get corruption while soldering.
• using same kovol 140 charger and cheap EPR cable
• @Ralim I'm wondering if there is something wrong with my new V2 . both of them soldering with all same variables, one is fine no corruption during soldering at all, and the other one is corrupted within minutes of active soldering and it happens every time. the Good one only gets corruption if I leave it to idle a long time but not while actively soldering.
• but how to I prove this or fix this? this same V2 that gets more corrupted screen, also strangely shows less volts on every single charger I have. if the good one shows 28V, the bad one shows 27.5V, similar if I use 20V charger.

[Ralim]

The most likely issue here is just the OLED / I2C bus. At the moment we are running the I2C bus faster than required so my first plan is to test lowering it down. Just want to unbox my gear and get some good looks at the I2C bus to see if we are running it on the edge of stability. (Will try adjusting the timing to see).

I would expect something like 5-10% variance once we add up all the part tolerances; so if we are near the edge as it stands that would explain this. If so; we can just drop speed by like 10-20% without any drama. Partially not helped by less than clear docs on the I2C in the BL706 when I was setting it up.

Main way I plan to look at this is:

(1) Make test firmware with different I2C settings and compare (2) Look at the bus data stability and timing (3) Most likely adjust timing or slow down

And finally;4, where I have a mild hunch that something in the I2C doesn't like display on/off toggles. I've wondered if the voltage rails go a little unstable. Have thought about having a bit of a backoff where after toggling on/off we force a few ms of bus silence for it to stabilise.

I suspect the snow is mostly the I2C in the OLED getting out of sync to the data. As dropping a bit during commands would cause this skew.

[River-Mochi]

I could also test this week only soldering with PD20V-65W charger to see if this eliminates snow/corrupted words?

[robertlipe]

@Ralim , I have a not-yet-unboxed Pv2. I have some of the satellite boards left from Pv1. If it's useful for me to solder headers onto one and get an analyzer on the i2c bus, I can do that closer to the weekend. (I'm not totally sure how those satellite boards work and whether that's the RIGHT i2c, for example.) I could try to get a scope and trigger leading power edges if you can guide me on what to look for. (I'm not a hardware guy, but I can usually follow instructions.)

Is it troublesome that writeRegistersBulk() grabs and releases the i2c lock on every byte moved instead of once at the beginning and releasing it once at the end? Would a higher level lock around the whole txn be needed? I can't find that pause_ms is ever non-zero, so instead of calling I2c_registerWrite, which hardcodes the size to 1, coiuld it call mem_write for the entire block to reduce lock transitions and get tighter i2c bursts as I2C_MasterSendBlocking() fills at the FIFO level instead reconfiguring i2c for every byte.

Just slowing down the i2C clock is a "take two aspirin" shot. There's 144Mhz of compute and a paltry number of pixels and refresh - you're not streaming YouTube to it at 4K. I couldn't find where it's set, but surely 400k vs. 1Mbps won't matter as a test case, would it? If that's easy to tweak and betas are cheap, maybe try that as speculation.

As a test case to exercise this theory would it be worth a debug mode that perhaps started another thread that did nothing but invert the frame buffer and then called OLED::refresh()? It would be annoying as heck to look at, but it would exercise potential i2c streaming issues faster. Maybe no thread needed. Just do this until a button is pushed. I don't know what would be needed to keep thermal and power supply happy if doing this in too tight of a loop.

I had another product in my life long ago that had power rail issues on the display. Instead of fixing the defective hardware, the "solution" was for software to ramp up the backlight like bad bar dimmers and to redraw the screen slowly because a storm of i2c and slamming the pixels around was more harsh than a gentle, long-running ramp of the backlight (this is emissive OLED. I know. It's different) and a slow tinkle of screen "animating" into place was less likely to trigger it. That product is long gone...

LMK if you want to pair-debug it or me to coding something like the pixel flipper under your guidance and I'll try to get my satellite board soldered up and get a build environment set up for it.

New hardware is hard. That's why it's named that. :-)

[mikerocklewitz]

I have this oled issue after adding hall sensor on one for sure. Not sure about the other yet havent rly used it much. Appears randomly. May have been happening before the hall sensor im not sure lol. 20v pd

[River-Mochi]

update on further usage: using the V2 for a while now and only using PD65 cable all week, confirming that corruption of the oled screen happens often during soldering, even just a few minutes of soldering, not when it's hot or long use.

In the normal course of using it or placing it in stand and back and forth, I have to flip it over or shake it pretty much every time I look at screen, the OLED is messy and I have to flip it to clear/refresh screen.
I find myself grabbing my V1 more and avoiding the V2 so I can work with a steady screen and know whether it's hot/heating or sleeping and needs (+) button hit.

[mikerocklewitz]

update on further usage: using the V2 for a while now and only using PD65 cable all week, confirming that corruption of the oled screen happens often during soldering, even just a few minutes of soldering, not when it's hot or long use.

In the normal course of using it or placing it in stand and back and forth, I have to flip it over or shake it pretty much every time I look at screen, the OLED is messy and I have to flip it to clear/refresh screen.
I find myself grabbing my V1 more and avoiding the V2 so I can work with a steady screen and know whether it's hot/heating or sleeping and needs (+) button hit.

Can confirm. Happens moreso when soldering. Cannot reproduce it on the bench or in a stand.

[River-Mochi]

maybe could I get a build from "test-slow-i2C" branch? I could test that even if it's slower screen draw to see if corruption completely goes away. This would either confirm or deny the hypothesis that it's related to I2C clock as it might not be.

I could report back after some soldering which is where it affects me the most.

[River-Mochi]

Could people with snow corruption screen let me know . Did all of you install a Hall Effect sensor at U14 or not? thanks

[mikerocklewitz]

Could people with snow corruption screen let me know . Did all of you install a Hall Effect sensor at U14 or not? thanks

I have installed a hall sensor. But the snow effect is not consistent. Very random actually. I can never make it happen. Sometimes it happens soldering. Sometimes it doesnt.

[VICLER]

Could people with snow corruption screen let me know . Did all of you install a Hall Effect sensor at U14 or not? thanks

I have not installed anything. I have this corruption on a new device out of the box

[River-Mochi]

thanks

[ghost]

I still have it on an unmodified V2 running 20.5416783. It does seem improved over the original firmware. It doesn't start to snow nearly as quick as it used to.

[jjwebb]

I found this issue page by googling "2.18.A1A569A". I have this same issue with an off-the-shelf Pv2 I just bought, with that firmware. Screen goes snowy after idle time or soldering. Only way to fix it is to unplug it, and plug it back in. 65W 20V USB PD. I set the idle and solder screen to "detailed" straight out of the box; I'll see if disabling that makes any difference.

[River-Mochi]

I found this issue page by googling "2.18.A1A569A". I have this same issue with an off-the-shelf Pv2 I just bought, with that firmware. Screen goes snowy after idle time or soldering. Only way to fix it is to unplug it, and plug it back in. 65W 20V USB PD. I set the idle and solder screen to "detailed" straight out of the box; I'll see if disabling that makes any difference.

don't need to unplug it, just gently flip it over and it will refresh the screen. gently flipping works better than shaking to re-draw the screen. there is a 2.20 beta I tried but the issue is not gone completely. Ralim is working on testing lower timing speeds to help with the noise/corrution. If you want to try the beta , go to Pinecil Wiki, links to community chat there, we have the Beta flasher in there that helps load the beta firmware. or just wait until Ralim makes the next beta since current beta still has i2C corruption.

[Aergan]

Hi there - I recently purchased a Pinecil V2 and had the issue with the display turning to "snow" / static when waking the iron from sleep using a 15V or 20V PD PSU. I tried the 2.20 beta FW and this actually made the issue worse & shaking/tilting did not clear it; only unplugging it.

The 2.20.3A96FF1 branch (https://github.com/Ralim/IronOS/tree/test-slow-i2c) however has resolved the issue entirely for me.

Model: Pinecil V2 Firmware Used: 2.20.3A96FF1 (https://github.com/Ralim/IronOS/actions/runs/3409043351) Charger: PD 65W (https://www.amazon.co.uk/gp/product/B09LV39WGL) Tested throughout the day, approx 2hrs soldering time over 11hrs with the iron left plugged in and going to sleep when not in use. Issue no longer occurring.

[River-Mochi]

For most people right now, recommend to just use firmware beta version 2.20.3A96FF1 from bottom of page of this Action link . Get the Pinecilv2.zip and pull the Pinecilv2_EN.bin from it. you don't need anything else from the zip.

1. It fixed all my i2C corruption using PD65w, 20v, 3.25 Amp chargers. Tested while soldering.
2. Only problem is it makes all my EPR 140W chargers reboot/not work. as long as you don't have a PD3.1 charger, it should work. This is not a fix for people with PD3.1 140W chargers.
3. Please try this and report a comment if 2.20.3A96FF1 beta works for you or not. Go to bottom of this page. https://github.com/Ralim/IronOS/suites/9161524538/artifacts/426541610

You also need a Flasher to load it on Pinecil V2.

1. Flasher: we have a command line one for Linux and one for Windows. you can get them from Pinecil Community chat for now since they are not fully released. All the different community chat links are in Pinecil Wiki . Since I only have Discord, I posted them to PINs at the top of Pine64 Pinecil Discord. If you join by Telegram, just ask someone in Pinecil and they could help you or search for words "Blisp Flasher" and you will find it.

2. To put Pinecil into Flashing mode. Connecting to a Linux or Windows PC is the same: Connect Pinecil V2 to PC by long holding down (-) button first, then plug in usb-c cable to back of Pinecil. Release the (-) button after 20 seconds. (do not plug in cable to V2 until you have (-) button pressed down first).

3. V2 screen will stay BLACK/blank which means you are in flashing mode, otherwise repeat step 2 or find another usb port/cable or PC since you are having connection issue with the PC port or cable.

4. Flasher for windows and Linux is also in one of the later Post in this Thread. see here

[mikerocklewitz]

Will try tonight/tomorrow.

[River-Mochi]

For Windows users. Successful Flashing of V2 in Windows Poweshell looks like this

[River-Mochi]

For Windows users. Files that should be in the Windows Folder and data folder for this to work. The Bin file you get from either Pinecil release zip in Github, or from Actions zip if it's an unreleased Beta, or from Ralim or trusted source if he made a special tester firmware he sends out. V2 only uses the BIN file for the language you select and the rest of the Firmware Zip can be deleted.

[mikerocklewitz]

Instructions for a real os (manjaro)?

[robertlipe]

Insulting the volunteers that are trying to help you for free is unlikely to help your cause. The commands provided with the bright orange square around them above are almost literally valid bash syntax.

Besides, a "real OS user" would have no problem recognizing backward DOS slashes and turning them into forward UNIX path separators. You don't have to use the DOS exe extension, of course. (See how that feels?)

Literally, run the blsisp executable (with the same relative path to the .bins) with the arguments like write -c bl70x --reset path_to_the_new_bin_file - the idea is very much the same in Powershell or Bash on MacOS or Linux or anything else.

Be nice.

Message ID: @.***>

[dannahan]

FYI, I am using a USAMS 240W USB C PD3.1 cable and a 140W PD3.1 PD-089PT Adapter. Both cheap. Iron registers at 28V. However, when I would get the snowy screen, I would rotate the iron to switch orientation and that would fix the issue. No more snow.

[River-Mochi]

te the iron to switch orientation and that would fix the issue. No more snow.

yes same for me and many other people rotating refreshes the screen. but it's prefered we don't have to do this many times while soldering.

[River-Mochi]

Instructions for a real os (manjaro)?

• there is a Linux blisp executable. the screen capture I posted was for my Windows Powershell install only and not for linux.
• the Executable for Linux and instructions are posted in Discord , and it's pinned but if you only have Telegram, or other chat you can also get to it.
• See Pinecil Wiki for links to chat https://wiki.pine64.org/wiki/Pinecil#Community_Chat_links
• and then you can see info on Linux flasher and instructions for Linux with Blisp, it's all in the Community chat channel. easier to get to if you have Discord since it is pinned there but also possible from Telegram too.
• when you join the live chat, just say you are looking for Linux Flasher. if you have Discord, just look in Pins at top of Pinecil Channel.

[River-Mochi]

Besides, a "real OS user" would have no problem recognizing backward DOS slashes and turning them into forward UNIX path separators. You don't have to use the DOS exe extension, of course. (See how that feels?) Literally, run the blsisp executable (with the same relative path to the .bins) with the arguments like write -c bl70x --reset path_to_the_new_bin_file - the idea is very much the same in Powershell or Bash on MacOS or Linux or anything else. Be nice. Message ID: @.***> …

• Screen shots I posted are simply showing for Windows users the files you need to do flashing and what flashing looks like in Windows for Windows users. I just did "ls" command to list what is in my folders of the flasher before I'm about to execute flashing in Windows PC using windows powershell command line.
• not showing at all Linux because I dont have linux presently to screen shot.
• did not provide any instructions for Linux flasher install here . only Windows Powershell install as that is what I have.
• get Linux flasher and instructions by joining Pinecil live chat like discord see here for instructions for that. https://github.com/Ralim/IronOS/issues/1417#issuecomment-1316173914
• it's fairly easy to do on linux too but it's a different flasher build.

[mikerocklewitz]

Lord help me you actually took offense to a comment like that? seriously?

I've helped people out in here in the past with the hall sensor on v1. My intent was not to insult or offend whatsoever. Nothing more than a cheeky remark. I have windows machines too.

I didn't need a guide for Linux. The link with the files was self explanatory to me. Thanks though.

[River-Mochi]

2. onnect V2 to PC by long holding down (-) button first, then plug in usb-c cable. Release the (-) button after 20 seconds (do not plug in cable to V2 until you have (-) button pressed down first).

I didn't notice it. looked like you were joking. at least i wasn't using an apple mac ;)

[River-Mochi]

I just installed the newest 2.20.3A96FF1 update and it seems to have gone away

This firmware is from Action "Testing slower I2C for PinecilV2 #2388" if it would just work for PD140W chargers, we would be done :)

[River-Mochi]

If anyone is willing to send Ralim some UART logs, it would help him narrow down and tweak the firmware.

1. First need to flash this special UART debugging firmware that ralim made version 2.20.A1510E 14-11-22 attached Pinecilv2_EN.bin

Pinecilv2_EN_UART.zip

Ralim's request:

If you need clarification for UART testing please ask Ralim in here for documentation.

2. We have a command line Windows or Linux flasher for now:

• Windows Blisp Flasher is attached.

blisp-win64.zip

• Linux Blisp Flasher is attached (could also build from open source code here

Linux_Archive.tar.gz

3. Any problems or issues with Flasher, please go to Gamiee's repo: https://github.com/pine64/blisp
4. Even though I don't have a linux PC , I did write up instructions from different linux installs people did. Instructions are in the "Pull Request" section of the github blisp flasher linked (as they have not been merged with the blisp repo yet).
5. It is called blisp flasher because the MCU in pinecil is the BL706. (blisp = Bouffalo Labs ISP tool & library).