Screen goes black

[theflynn49]

Sometimes, the screen goes totally black, until reboot while playing Catskillvania.

• it's probably not a hardware problem because it happens to my two boards, even if I switch screens
• it happens only during transitions condo<->hallway or menu->hallway
• sometimes instead of totally black it turns blueish, indicating a probable screen failure due to comm errors

this patch fixes the problem
file Catskill.ino
line 377 is
nextFrameFlag -= 2;
should/be
nextFrameFlag = 0 ;

• I don't provide a PR because I have no idea why this fixes the problem. To my understanding, this only avoids successive continuous frames to be sent to the screen whenever there is a contention. I am not totally satisfied by this explanation.

Nevertheless this may help some poor soul having the same problem.

note : symptom looks like if you program your pico at 133Mhz; SPI clock goes berserk and screen goes black very often. I made this mistake too.

[benheck]

Yeah you have to run it at 125MHz which is an Arduino/IDE/programming setting. Reason is the SPI bus is CPU/2 = 62.5Mhz If you go higher (133/2 = 66.5) you exceed the ST7789 LCD input speed (which tops out around 63MHz)

…

-Ben

On Mon, Feb 5, 2024 at 6:46 AM theflynn49 ***@***.***> wrote: Sometimes, the screen goes totally black, until reboot. - it's probably not a hardware problem because it happens to my two boards, even if I switch screens - it happens only during transitions condo<->hallway or menu->hallway - sometimes instead of totally black it turns blueish, indicating a probable screen failure due to comm errors this patch fixes the problem file Catskill.ino line 377 is nextFrameFlag -= 2; should/be nextFrameFlag = 0 ; - I don't provide a PR because I have no idea why this fixes the problem. To my understanding, this only avoids successive continuous frames to be sent to the screen whenever there is a contention. I am not totally satisfied by this explanation. Nevertheless this may help some poor soul having the same problem. note : symptom looks like if you program your pico at 133Mhz; SPI clock goes berserk and screen goes black very often. I made this mistake too. — Reply to this email directly, view it on GitHub <#3>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABMEESOTJWZNINFSBO6777DYSDIDTAVCNFSM6AAAAABC2COJDOVHI2DSMVQWIX3LMV43ASLTON2WKOZSGEYTQNBWGM2DMOA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

-- Benjamin J Heckendorn www.benheck.com

[theflynn49]

@benheck : thank you for your answer !

Nevertheless, I failed to be completely clear : despite running at 125Mhz, it still fails once a minute or so.

I tried a zillion things, but to fix this the only thing I found is to reset nextFrameFlag to 0 line 377 of Catskill.ino

jF

[benheck]

Weird. Here's the most disappointing thing one can say in coding: I haven't had that happen on any of mine. Are you using a Waveshare ST7789? I've had issues with brands other than that. I need to fork it as that model is getting hard to find.

…

-Ben

On Mon, Feb 5, 2024 at 11:32 AM theflynn49 ***@***.***> wrote: @benheck <https://github.com/benheck> : thank you for your answer ! Nevertheless, I failed to be completely clear : despite running at 125Mhz, it still fails once a minute or so. I tried a zillion things, but to fix this the only thing I found is to reset nextFrameFlag to 0 line 377 of Catskill.ino jF — Reply to this email directly, view it on GitHub <#3 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABMEESMRVP2F3LFL2M7IC7TYSEJSDAVCNFSM6AAAAABC2COJDOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMRXGU2DANRRGE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- Benjamin J Heckendorn www.benheck.com

[theflynn49]

Thanks again for your help.

I am using Waveshare's ST7789 1.3 inches from Amazon (France), and I even tested with 2.0 inches models since I ordered the wrong type at first. Same symptoms with all screens.

Maybe I am using a different version of compiler, or so, and it generates something a little too slow. May I try the exact same uf2 file you are using to discard this hypothesis ?

On another hand, the problem always happen during condo<->hallway transitions, or menu -> hallway, and never ever at some other time, which seems to imply that the external flash operation collides somehow with something, and that it is not hardware related.

jF

[theflynn49]

Hello again. I've been working on this lately, and the following scope capture might well be where the problem is. The trigger is (magically) set to show exactly when the screen freezes.
Yellow = SPI clock (screen) Blue = DC to screen
The yellow block is slightly shorter than the normal ones (as I see on other captures) 15.8ms instead of 16.4ms which seems to indicate that the transfer was somehow aborted.
Why would DC go low before the end of the previous block ??

This capture is made with your version of Catskill.ino. With the "nextFrameFlag = 0" patch, there is no more block collision.

[theflynn49]

@benheck : Hello ; I am confident I finally nailed it, I made a PR for this, I hope you like it.
My Best.

[benheck]

Were you making a custom game? I'm not sure I ever ran into this on Bud Game. You just adding DMA command blocking right? It's been a year so I of course forgot EVERYTHING about this code :)

…

-Ben

On Wed, Feb 7, 2024 at 8:06 AM theflynn49 ***@***.***> wrote: @benheck <https://github.com/benheck> : Hello ; I am confident I finally nailed it, I made a PR for this, I hope you like it. My Best. — Reply to this email directly, view it on GitHub <#3 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABMEESLU4326MV6O4MHVCXTYSOC7BAVCNFSM6AAAAABC2COJDOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMZSGEZDGMZQHE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- Benjamin J Heckendorn www.benheck.com

[theflynn49]

No no new game unfortunately :D I was testing on Bud Game; but this issue is time-related and I am convinced that my batch of screens are more sensible to aborted frames, because these aborted frame are systematic in the transitions hallway<->condo, but don't necessarily lead to a black screen.

Anyway, the bug is obvious once you get in the logic there.
Thank you for the PR, feels good, and for the Bud Game which is really fun to play :D

[benheck]

Probably right. The screens do vary. That's why I used Waveshare because I know they work.

…

-Ben

On Wed, Feb 7, 2024 at 4:59 PM theflynn49 ***@***.***> wrote: No no new game unfortunately :D I was testing on Bud Game; but this issue is time-related and I am convinced that my batch of screens are more sensible to aborted frames, because these aborted frame are systematic in the transitions hallway<->condo, but don't necessarily lead to a black screen. Anyway, the bug is obvious once you get in the logic there. Thank you for the PR, feels good, and for the Bud Game which is really fun to play :D — Reply to this email directly, view it on GitHub <#3 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABMEESPB5IF5UXVPDQVPVMDYSQBMVAVCNFSM6AAAAABC2COJDOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMZTGA3TGOJSG4> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- Benjamin J Heckendorn www.benheck.com

[theflynn49]

@benheck
Hi Ben !

I just found another nasty bug involving this issue, so I reopen it.

In state 0 or 1 of LCDlogic() in gameBadgePico.cpp, I wait for the previous DMA cycle to be completed, but I also MUST wait for the SPI to be quiescent to go on with the next cycle, because the first thing it's going to do is toggling the screen's DC signal while the SPI is still sending its data if the timing is playing with us.

Note that in state3, you don't have to do that, because the DMA is handling the SPI correctly while the screen stays in DATA mode.

I can make a PR for this if you want, let me know, or you can take the version in my fork.

Rgds
jF

[benheck]

If this doesn't affect existing games make a PR.

…

On Sun, Feb 25, 2024 at 5:16 AM theflynn49 ***@***.***> wrote: Hi Ben ! I just found another nasty bug involving this issue, so I reopen it. In state 0 or 1 of LCDlogic() in gameBadgePico.cpp, I wait for the previous DMA cycle to be completed, but I also MUST wait for the SPI to be quiescent to go on with the next cycle, because the first thing it's going to do is toggling the screen's DC signal while the SPI is still sending its data is the timing is playing with us. Note that in state3, you don't have to do that, because the DMA is handling the SPI correctly while the screen stays in DATA mode. I can make a PR for this if you want, let me know, or you can take the version in my fork. Rgds jF — Reply to this email directly, view it on GitHub <#3 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABMEESO5SINCZ63R5E77U3TYVMMRZAVCNFSM6AAAAABC2COJDOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNRSHA4TQNZSGY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- Benjamin J Heckendorn www.benheck.com

[whatskenmaking]

@theflynn49 thanks for jumping in! Quick question for you - which version of the gameBadge are you using, 3 or 3B?

[theflynn49]

@kenstcyr Hi there. I use both. Both work well.

[theflynn49]

@kenstcyr ... After re-reading this, I think you want to know with what version I experienced these screen problems ... I was using mainly the version 3.