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.

[River-Mochi]

Things needed for UART testing to get logs when V2 i2C starts corrupting screen:

1. pinecil Break- out board from Pine store. OR something like this PCB from Amazon was suggested by @prokrypt if you don't have pinecil board.
2. A cable connector to go from the pins of the break-out board in (1) to the PC. Could get this that part clips onto the break-out board from (1). Then used your own USB cable on that to the PC.
3. this part was recommended by @prokrypt because it has a real FTDI chip in it which may have less issues with communication over cloned chips (especially for windows).
4. we want 3.3 V and not 5V for the UART.
5. UART baud rate might be 2000000 , thanos said to check 9600, 115200 if 2000000 doesn't work and you get garbage data

there is also this part that may work for (2) above , it's only $5.99 worth trying out, if it doesn't work could return to amazon. Potato suggested in Pinecil chat to just get something with a real FTDI chip stuff so you don't have headache of it being flaky. I'm going to get both and try them, if $5.99 cable doesn't work I can return it.

[River-Mochi]

Pinepony found this evidence that it is Baud rate 2000000 from IronOS code.

[NovaViper]

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 :)

Ah I don't have any PD140W chargers (the most I have is 65W)

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

And sadly, I don't have a UART breakout board so I can't get any debugging logs 😭

[River-Mochi]

@Ralim

1. UART firmware beta is not working for me, it's causing V2 to reboot without stopping (kovol 140W charger)
2. version 2.20.A1510E 14-11-22 reboots fails on both EPR Apple & Kovol but different behavior
3. did you want me to just do Uart testing with PD65 or wait for you to fix one that has UART messages and can work on EPR chargers?
4. same thing happened when I tested this beta: "Testing slower I2C for PinecilV2 #2388" - it only worked for PD65 chargers so I stopped testing it.
5. Does this UART beta include the corrections for the 0x00 ignore padding problem of Kovol and the fix for the Anker 717 problem?
6. Kovol 140w reboots continuously like it did before padding fix.
7. Apple is different. as you recall the Apple 140 originally worked with stock 2.18, but the PD debug menu never worked in 2.18. it just kept rebooting in PD debug without stablelizing at State 12. In UART ver 2.20.A1510E the PD debug problem re-appears (PD debug reboots and never stable) And an additional problem now.

Sometimes when I plug it in screen is fine and I can heat. every 3-4 times i plug it in the screen reboots within the first 5 seconds and it just keeps rebooting every 5 sec or so and I also see PD State messages appear every now and then when it's rebooting (even though I'm in normal screen). in between reboots, If I hit (+) it sometimes heats up and stops rebooting or it heats then reboots again but in between reboots i can get it to heat. If I keep plugging it in cable, sometimes it's stable and I can Heat without more reboots, but I haven't tested it soldering to see if it would interrupt and reboot on me more during use.
most of the tests when I plug it in, it just reboots about every 5 seconds and I just unplug it after I see about 10 reboots since it's probably not going to stop. ver A1510E is less stable than 2.18 in that now the Apple doesn't work consistently even if I ignore PD Debug strangeness.
The rebooting in the Apple is also not as fast as the Kovol reboots, longer time by a few seconds between reboots, and unlike kovol when the Apple is between rebooting, I can sometimes hit (+) and get it to heat up. What is consistent and easily repeatable is PD debug States is unstable, and never settles at State 12 even holding (+) down before plugging in and holding it for long time 1 min ( does not reach state 12). If I let go of (+) it goes to main menu instead of staying in PD Debug.

8. If I use non-EPR cable like a PD60 cable, then all the EPR chargers work because they are not doing EPR. PD state is stable and everything works normally because they operate at only 20V PD3.0 state.

[NovaViper]

Reuploaded to remove sensitive information

Can confirm that I'm also getting the same corruption issue on my Pinecil V2 using the beta 2.19 software. I noticed it particularly when I was soldering a SMD chip for a TV circuit board, would just mess up the numbers on the screen with little dots all over (not as bad as op but definitely would make reading the numbers impossible). Sadly I don't have any pictures of it but I noticed it happening if I rotated the iron around too much (which I tend to do because I'm trying to reach different parts of whatever I'm working on).

I just installed the newest 2.20.3A96FF1 update and it seems to have gone away (at least from me just rotating it over and over again about 30 times rapidly) to see if I could trigger it again. Will update if I manage to replicate it again

The PSU I used when I got the original bug was the RavPower PD Pioneer 65W 4-Port GaN Tech USB C Desktop Charger (only the iron was plugged into it at the time). I think it was this firmware action I was using as well: https://github.com/Ralim/IronOS/actions/runs/3409043548

[River-Mochi]

not_daniel suggesting that Uart firmware is failing on EPR chargers maybe because the firmware is waiting too long to send Chunk Messages.

[River-Mochi]

I just installed the newest 2.20.3A96FF1 update and it seems to have gone away (at least from me just rotating it over and over again about 30 times rapidly) to see if I could trigger it again. Will update if I manage to replicate it again

Normally the corruption just happens out of the blue. then flipping it redraws the screen. @NovaViper could you confirm. it might appear flipping it is causing it, but I think it just happens randomly while soldering or whatever I'm doing and then gently flipping it actually fixes it by forcing a re-draw of the screen which happens if you also have Auto screen orientation enabled. since flipping it over gently activates Accelerometer screen re-draw it would be odd if flipping it is causing your corruption. Are you sure it was flipping that caused it rather than flipping fixing it? sometimes corrupt screen appears just leaving it sit idle for a few minutes. but so for for me at least , a simply gentle flip Re-draws screen (shaking it does not work).

[mikerocklewitz]

Linked firmware flashed on both my v2's using powershell 🤣. Had issues with getting the 2nd handshake on each one. 2nd one erased then failed. Couple tries to get both to flash - they heat up and hall sensor appears functional still. Will report back if any issue, not doing any soldering today.

I could maybe try to give the uart thing a go. I have an official breakout board and several different USB-c breakout options as well.

[River-Mochi]

I dont see link. you tried to update using Windows blisp flasher? if it failed- did you make sure to put the .\ in front of Both the word blisp and the Pinecil file? in windows Powershell, change into the Directory for the flashing , make sure Pinecil...bin is in the folder with the blisp executable and Either hit tab after you type blisp word and then hit tab after typing Pinecil word, or just put the ".\ " Could you join to Discord live chat? it'smuch easier to do live troubleshooting. Literally takes no more than 1 min to flash this, but sometimes there is just 1 thing people are doing that is slightly different that causes failed flash.

We also have a Linux flasher if you prefer.
Join Community Chat , Volunteers can probably Figure it out more quickly in there why flashing is not working for you.

If The First half of install worked but not the 2nd part, then I suspect:

1. move Pinecil.bin to same folder as blisp.exe
2. Pincil..bin is named incorrectly, use the exact name as you see in Windows Powershell screenshot above just to make it easier. or from if your cursor is already inside blisp folder, just type "Pine" hit Tab and it will auto complete correct name with the needed .\ for it.
3. or the ".\" was not used with the names. need the .\ in front of.\blisp and in front of .\Pinecilv2_EN.bin refer to exact way command is written in the Screenshot above that also has the Log of install.
4. Could you Drag Screen shot here of the Error and commands you typed into Powershell?
   if you come to Discord chat just shout out you need help installing BETA firmware for V2. and which OS you prefer and a volunteer will help if someone is around. https://discord.gg/pine64 link to join is also in Pinecil Wiki if you prefer to join by Telegram or matrix. Main chat is in discord but they made bridge bot that copy/pastes all chat between 4 different chats. you don't get to see/use all discord features, but other chats can at least chat with us.

[mikerocklewitz]

I was able to get it to flash. I'm just stating it took multiple tries before I was able to get past the 2nd handshake. No errors except failed handshake.

I wasn't implying i linked anything. I was referring to your linked files above.

Didn't try Linux. One of my windows machines was turned on when I flashed and it was convenient.

[River-Mochi]

I was able to get it to flash. I'm just stating it took multiple tries before I was able to get past the 2nd handshake.

I see you got update done on 2nd try using the same command. it could have been the cable or the port was flakey.

when people run into this, we sugest following:

• USB-C to C cable if possible as that is better, or if not possible then switch to a different other Usb-A to C cables that might do data transfer better (some A-C are just really bad at data transfer and no one notices as they mostly use their cable for power only) .
• Avoid any usb hubs and do direct connect to PC ports or laptop. On a PC, the rear ports can be better than front ports as front ones might be on an internal hub and wire and not direct connect to the motherboard.
• Another thing people try is flipping cable over as not all cables are made properly.
• Another trick that has been done for very flakey ports is hold the (-) the whole time and don't let go of (-) during the update process. I've not seen it need to get to that, usually it is resolved just using different port or PC/laptop or different cable.
• in Windows Device manager, you may notice that BL706 MCU connects to Windows differently than the old V1 did. It connects as a Serial COM device under Ports (COM & LPT)

[mikerocklewitz]

I concur - very likely a flakey cable.

[River-Mochi]

. 65W 20V USB PD. I set the idle and solder screen to "detailed" straight out of the box;

@jjwebb Could you try the firmware from this comment linked. Since you only have a PD65W charger, it should work for you. let us know how it goes. I detail in comment exactly how to get the Zip.

https://github.com/Ralim/IronOS/issues/1417#issuecomment-1316173914

[River-Mochi]

This issue is resolved in 2.20 latest release stable firmware now so I am closing the ticket