Sorry for the typo 1 means 1 sec, 0.1 means 100 ms, 0.01 means 10 ms and 0.001 means 1 ms.
Hey after all testing I finally confirmed that the U1 driver of the display is damaged. I tried both i2c and without i2c. The first 8 cells on each line behaving very strangely.
Nope, 0.01 is 10 ms. 0.001 is 1 ms.
Yes. I have just checked mine and corrected the mistake. Thanks.
What language is that code?
I see several timing issues.
While it may appear to "work", the initialization sequence timing is incorrect.
It is not using the correct timing to ensure a reliable 4 bit initialization.
In particular sending the first few instructions of the 4 bit initialization sequence is very different than sending instruction in normal 4 bit mode since there is no assurances as to what mode the LCD is in when it starts. The LCD is in 8 bit mode when powered up but if it is already in 4 bit mode it could be waiting on nibble 0 or nibble 1.
So if you want initialization to be reliable, you can't just slam out pairs of nibbles during this part of the initialization that match the initialization sequence the same as is done once the LCD is in 4 bit mode and expect that just because the nibble stream sent matches the initialization instruction sequence in the data sheet that it will always work.
Depending on the state the LCD is in when this starts, some instructions of that initial sequence could be lost (the LCD ignores instructions if it is busy) since you must have delays between the nibbles to give the LCD time to process each nibble as an instruction.
This is because during the 4 bit initialization sequence, individual nibbles can and will be interpreted as instructions and need some delay time for the instruction to be processed.
The datasheet gives the timing delay values needed based on a worst case instruction execution time for an instruction that is executed in the case where the nibble completes a "random" instruction due to the LCD being out of nibble sync when the sequence started.
In your case, the 0x33, 0x32 sequence is sending 4 nibbles.
If the LCD is in 8 bit mode when it starts,
That is actually 4 LCD instructions. 0x30, 0x30, 0x30, 0x20
But the delays between those instruction is not correct.
It is worse if the LCD is already in 4 bit mode and waiting on nibble 1
since a random "garbage" instruction can be executed so there must be a delay to accommodate the longest instruction time.
Also, once in 4 bit mode, no delay between nibbles of a instruction byte is necessary.
You do however, have to make sure you still honor the E timing of tAS and tcycE for the nibble pair.
To eliminate a s/w initialization and/or timing issues, I would run a known working LCD library.
Assuming you are using a backpack that uses a PCF8574 i2c i/o expander,
My recommendation would be to install the hd44780 library.
It has an io class called hd44780_I2Cexp that supports that interface.
Then run the included I2CexpDiag diagnostic sketch.
Post back with the results of the diagnostic test.
If it runs correctly then you have s/w issues in your code that are causing these weird effects.
--- bill