That really isn't so much a solution. It is more of a work around.
If you think that the LCD is taking longer to execute the CLEARDISPLAY command,
you can increase the delay down in the library clear() function to compensate for it.
Go edit LiquidCrystal.cpp
and change this:
command(LCD_CLEARDISPLAY); // clear display, set cursor position to zero
delayMicroseconds(2000); // this command takes a long time!
to use a longer delay.
Change the 2000 which is 2ms to something longer like maybe 4ms or even 8ms at
for testing to verify it or rule it out.
Then you may want to back into a smaller value if you are worried about performance
But I'm not convinced for sure that the delay is too small for the CLEARDISPLAY command.
The cases where I've violated the timing on a command merely caused some data or commands
to be lost not full screen corruption and it eventually recovers.
So nothing in the h/w was changed? No moving of wires, or changing of any signals.
When it "worked" it was just a s/w change to avoid using clear()?
I guess depending on the internal design of the lcd module and
if the timing was just right, it is possible that the host and the display might lose nibble since
and then everything would be crap on the screen from then on.
The cases of full display corruption that I've experienced have been due to nibble sync being lost
from false E signal transitions and were due to ground bounce or ground loops from too little decoupling or multiple power
wires on multiple power rails on a breadboard, like what was shown in the photo.
In most of my cases it was when I was using a 595 shift register to interface to the hd44780 pins
and the 595 was clocking on noise or a gound bounce which corrupted the output pins
which created false E transitions. The 595 is extremely sensitive to noise and ground bounce issues.
But something similar could happen in 4 bit mode as well.