LCD garble after a while on ATTINY1614

[mart-jakobson]

Hi, Thank you for an awesome library, many time user, first time poster :)

I was sort of stress testing some chinese i2c 16x2 lcd-s for an upcoming project and ran into an issue now well over my head..
It seems like I'm losing some byte nibbles. Would guess a noise issue, but I can't find any noteworthy noise.

Test env: AtTiny1614 on a breadboard in a relatively noise free enviroment. Powered from quiet 5v linear psu and decoupling caps on the chip and lcd. I2C ran as a 20cm twisted pair separate from power. I2C pullups standard 4k7 on lcd backpack verified.
I2C backpack IC is PCF8574T.

Repro: Run unmodified LCDiSpeed400, unmodified LCDCharset and simple:

{    lcd.clear();
    lcd.setCursor(0,0);
    lcd.print("1 2 3");
    lcd.setCursor(1,1);
    lcd.print("123");
    delay(1000);
}

No repro: LCDCustomChars, I2CexpDiag

quick video: https://www.youtube.com/watch?v=DFSSwByl3JQ

Edit: no repro on Atmega328 and Attiny85 under similar test conditions.

I2CexpDiag output:

I2CexpDiag - i2c LCD i/o expander backpack diagnostic tool
--------------------------------------------------------------------
hd44780 lib version: 1.3.2
--------------------------------------------------------------------
Reported Arduino Revision: 1.8.13
CPU ARCH: AVR - F_CPU: 20000000
--------------------------------------------------------------------
SDA digital pin: 6 A10
SCL digital pin: 7 A11
--------------------------------------------------------------------
Checking for required external I2C pull-up on SDA - YES
Checking for required external I2C pull-up on SCL - YES
Checking for I2C pins shorted together - Not Shorted
--------------------------------------------------------------------
Scanning i2c bus for devices..
 i2c device found at address 0x27
Total I2C devices found: 1
--------------------------------------------------------------------
Scanning i2c bus for all lcd displays (4 max)
 LCD at address: 0x27 | config: P01245673H | R/W control: Yes
Total LCD devices found: 1
--------------------------------------------------------------------
LCD Display Memory Test
Display: 0
 Walking 1s data test:	PASSED
 Address line test:	PASSED

[mart-jakobson]

After further testing, it seems to be caused by lcd.clear().

Eg. loop with

lcd.clear();
lcd.print("Foo");

fails after a while,

but loop with

lcd.setCursor(0,0);
lcd.print("   "); // Three spaces
lcd.setCursor(0,0);
lcd.print("Foo"); 

doesn't fail

[bperrybap]

Interesting. First, nice to know that the code is "working" on that platform.
I don't have that hardware so I won't be able to reproduce your environment.
I was unable to reproduce it on m328, pic32, or esp8266 based boards.
Can you point me to the platform core code you are using?

Given it appears to only happen when clear() is used, it appears to be an issue related to the clear / home instruction timing.
This could be caused by a few different things

• hd44780 library is not handling the timing correctly
• the Arduino platform core code for attiny1614 is not handling micros() correctly
• the LCD is a bit slower than the default timing used by the hd44780 library
• the i2c bus is actually running faster than 400 kHz
• there is some kind of timing issue that arises when running with the CPU clock at 20mHz
• the processor is actually running faster than 20mHZ
• the PCF8574 can't reliably run at 400kHz

While there could be a hd44780 library issue in how the timing is handled, given the code has been run and tested on so many different platforms and LCDs, my suspicion at this point is a micros() issue on that platform.

It is possible there is a i2c clock speed issue.
i.e. while it seems to work at 400kHZ, the datasheets I've seen only rate the PCF8574 to 100kHz.
Perhaps there is some sort of issue at 400Khz that triggers this like pullups need to be a bit smaller to reduce slew rates.

In the mean time can you try a few things.
Do a small test like delay(20000) to turn on/off an led and time it with a stopwatch to see if millis() is working properly.
If it is working ok, then do a small test to verify if micros() is working properly.
grab micros() delay(10) then subtract off micros() and see if the delta close to 10,000

• test the return value of the clear() to see if it is ever non zero

---

Next after doing those tests, is to increase the clear / home timing by adding this to your test code before your loop testing.
lcd.setExecTimes(3000, 38);
This will change the timing from 2ms to 3ms for clear/home and leave the default timing for the other instructions.

If that works, then we'll have to look closer as to why the default clr/home timing only fails on the 1614

If that doesn't work, then increase the second parameter from 38 to say 50 and see what happens.
If that works, then we'll have to look closer as to why the default instruction timing only fails on the 1614 when combined with clear()

[mart-jakobson]

Sorry, forgot to mention, SpenceKonde's megaTinyCore https://github.com/SpenceKonde/megaTinyCore

I'll test some more tomorrow. AFAIK micros() is working correctly, tho I'm using internal oscillator and haven't exactly tested its performance yet.

[bperrybap]

Any update on this?