LCD lights up, goes dark, doesn't display anything

[bjh]

Very excited to play with the LCD, but loading the "BasicUsage" sketch makes it light up, go dark and doesn't seem to display anything.  I assume if there were something wrong with the example the forums would be going crazy, what am I doing wrong?

[Mark]

I found its normal for the I2C display to light then go black.
(I haven't used the shield), then come back after the Digispark talked to it.

You may need to adjust the contrast. Set it until you see 32 black boxes, then back it off until you just see the top 16.
After that if you have text, you can adjust to suit...

Did you need to cut the trace.?

NOTE: If you have a “Model B” board you may need to cut the trace to the onboard LED before using any I2C devices - Find out how to tell which board you have and what to do here: modelbi2c

I presume you have it powered by something other than the computer ie a powered hub that isn't connected to the computer.
I found that the USB and the I2C would result in unpredicted behaviour, but I also had one wire running as well....

mark

[digistump]

In addition to what Mark said - is this a LCD that came with the kit we offered? After it goes dark it doesn't light up again?


Since it goes dark we know that it is getting a signal from the Digispark. It is worth trying with an external power source, also can you check if the LED jumper pins on the back of the LCD screen have a jumper on them?

[Mark]

No jumper would result in no light ....

If the I2C isn't communicating (either wire), it won't go dark, as its the lcd.int() that causes it to turn the backlight off initially.

When you say it lights up, then goes dark, I presume you are talking about the backlight...?

Its possible the shield isn't making good contact.
Have you used the standard pins or the stackable headers on the shield.?

mark

[bjh]

Better detail: this is the official LCD kit, the jumper on the back is in place, stackable headers with the twist, and by "lights up", yes, I was referring to the backlight. 


I've generally been powering from the computer, but so far, it behaves the same way when plugged into an iPhone charger. 


If I peg the contrast all the way up I see faint boxes on the top row, and nothing on the bottom. If I just apply 5v power and don't hook up data at all, the backlight stays on and with the contrast all the way up I see bright boxes on the top row and as I adjust down they turn to dark boxes and fade out, no boxes on the bottom row at any contrast level.

[bjh]

Oh, and it's "model A" (with "rev2")

[digistump]

I'm stumped here - as your Digispark seems to be communicating with the LCD, the LCD seems to be working - if you have a multimeter can you check the connection between the SDA line on the LCD and the Pin0 on the Digispark, and the SCL on LCD and Pin2 on Digispark?

[Mark]

bjh/Erik
Cheers for the update.

I've had a few issues when testing your scenario.
The display didn't blank and it was to do with the shield not making contact. (my headers had already been spread before I suggested the twisting)

Having played with a few I2C LCD sketches, and trying different things, I'm struggling to duplicate your scenario.
1. If the display lights (normal powerup), then goes dark, it is receiving the lcd.init over the I2C lines.
2. If the address is anything other than #define GPIO_ADDR     0x27 then it won't go blank.
3. Programming with the I2C hooked up (breadboard not shield) doesn't affect the programming.
4. If one or other of the 4k7 resistors is not connected it won't go blank.
5. If one of the SDA or SCk wires is not connected to the displayit won't go blank.
6. if the SDA and SCK are shorted it won't go blank.

Can you confirm the sketch is straight from the example, with no changes
Have you got anything else plugged onto the top of the LCD shield.

This is doing my head in .... but hopefully you can see that trying to identify the cause, means it can be sorted for future

Mark

 Erik ...the sketch details are wrong Mario set A0-A3 to GND, while these have A0-A3 set to +5v hence base address is 0x27, not 0x20

[bjh]

Definitely a flakey connection, went to unplug for reprogramming at one point, bumped it just right and the backlight came on suddenly!  I was then finally able to get it to display "Digispark!" 


Playing with it some more (actually while writing this post) it's looking like the problem is iffy USB power, as I wiggle the digispark in its socket, some positions turn the backlight on and some off.  If I keep it pressed in an "on" way, it successfully prints the message.


I added code to blink the onboard LED as a heartbeat, and it continues to blink regardless; so the power is "good enough" for the digispark, but LCD, especially with the backlight seems more sensitive.

[Mark]

I found that after initally inserting my Stackable headers into the Digispark socket, they may have become 'wider' than they should.

I rotated the stackable pins to 45 deg ( I need to go back and modify my post).
Perhaps yours has suffered the same fate.

You can try 'misaligning' them very slightly.
I'm set to do some photos tomorrow, so I might pull a damaged one apart to show the internals.

Glad you've resolved it .... well done.

For those interested, LCD's usually don't have much in the way of physical resets or watchdog timers, etc.
A power drop is needed to reset them, but you them need to reinitalise them.
My parents had a stove the control display went funny on. The service company replaced two under warranty at $3-400 a piece.
The third time (out of warranty) it went again and I got asked to check. Power off, wait 30 secs, power on all fixed.

I suspect this is similar where the power is dropped and needs a reinitialise.

Mark

[bjh]

Another evening's troubleshooting and here's what I've found: the stackable header pins should be twisted more like 60° than 90°, even if you didn't "stretch" your headers with the full width. 


Twisted 90°, they make contact well enough for some purposes, but not feeding a backlight without browning out the display controller.


A few more bits I found along the way:


- Backlights are thirsty, so trying to buffer the power requires a massive capacitor (saw some benefit with a 3300uF cap slightly smaller than a AA battery)


- The best way to measure connection quality is end-to-end voltage (not resistance, as in "what voltage is actually making it to the peripheral?")


- Mostly not an issue, but worth keeping in mind: the Digispark has a protection diode on the USB tongue which knocks the voltage down a bit, so even best-case isn't going to be 5v if you're powering it that way. (Which may also make sensitive things more susceptible to brown-out than they would be if they had just a bit more voltage, so give an external power supply a try, just to see)


--bjh

[bjh]

Oh, and:


- Super-useful to quickly flash the onboard LED incrementally increasing numbers of times as your setup() does its thing, and then settle on a regular "heartbeat" in your loop(). It helps associate what you're seeing with the lines of code and eliminate the "So... Did the bootloader finish? Should I have seen signs of life yet?  Etc..."

[Mark]

Thanks for the bending update.
I'll modify my post to 60 deg.
 
Can you post your LED flashing so that others can use/incorporate it.
 
That was one of the things I missed most, the abilty to send out serial.print("lcd intialised");
as a debugging tool.
 
 
Mark

[bjh]

I posted the core on Bluebie's awesome tricks page, here's the complete LCD valentine:

/* ATtiny85 as an I2C Master   Ex2        BroHogan                           1/21/11
 * Modified for Digistump - Digispark LCD Shield by Erik Kettenburg 11/2012
 * Modified for debugging and Valentine's day by bjh 14 Feb 2013
 * Added debug macros
 * SETUP:
 * ATtiny Pin 1 = (RESET) N/U                      ATtiny Pin 2 = (D3) N/U
 * ATtiny Pin 3 = (D4) to LED1                     ATtiny Pin 4 = GND
 * ATtiny Pin 5 = SDA on DS1621  & GPIO            ATtiny Pin 6 = (D1) to LED2
 * ATtiny Pin 7 = SCK on DS1621  & GPIO            ATtiny Pin 8 = VCC (2.7-5.5V)
 * NOTE! - It's very important to use pullups on the SDA & SCL lines!
 * PCA8574A GPIO was used wired per instructions in "info" folder in the LiquidCrystal_I2C lib.
 * This ex assumes A0-A2 are set HIGH for an addeess of 0x3F
 * LiquidCrystal_I2C lib was modified for ATtiny - on Playground with TinyWireM lib.
 * TinyWireM USAGE & CREDITS: - see TinyWireM.h
 */

#include <TinyWireM.h>                  // I2C Master lib for ATTinys which use USI - comment this out to use with standard arduinos
#include <LiquidCrystal_I2C.h>          // for LCD w/ GPIO MODIFIED for the ATtiny85

#define GPIO_ADDR     0x27             // (PCA8574A A0-A2 @5V) typ. A0-A3 Gnd 0x20 / 0x38 for A - 0x27 is the address of the Digispark LCD modules.
LiquidCrystal_I2C lcd(GPIO_ADDR,16,2);  // set address & 16 chars / 2 lines

// 0: Binary sketch size: 1,790 bytes (of a 6,010 byte maximum)
// 1: Binary sketch size: 2,114 bytes (of a 6,010 byte maximum)
#define DEBUG 0  // Set to 1 to enable, 0 to disable

#if DEBUG
#define DebugPin 1  // Digispark model A onboard LED
#define DebugBlink 75
#define DebugPause 300
#define debugDelay(ms) delay(ms)  // Change if you need a special delay function (e.g. if you use libraries that need regular refresh calls)

void _debugBlink(int n) {
  for ( int i = 0 ; i < n ; i++ ) {
    digitalWrite(DebugPin, HIGH);
    debugDelay(DebugBlink);
    digitalWrite(DebugPin, LOW);
    debugDelay(DebugBlink);
  }
  debugDelay(DebugPause);
}

void _debugSetup() {
  pinMode(DebugPin, OUTPUT);
}

#define debugBlink(n) _debugBlink(n)  // Do the blink when DEBUG is set
#define debugSetup() _debugSetup()
#else
#define debugBlink(n)  // Make the calls disappear when DEBUG is 0
#define debugSetup()
#endif

void setup() {
  debugSetup();
  debugBlink(1);
  TinyWireM.begin();
  debugBlink(2);
  lcd.init();
  debugBlink(3);
  lcd.backlight();
  debugBlink(4);
  //        |0--------9------|  // "ruler" for the 16 char LCD lines
  lcd.print(" I love you!!!!");
  lcd.setCursor(0,1);
  lcd.print("<B  @>-'-,--  <B");
  debugBlink(5);
}

void loop() {
  delay(500);
  debugBlink(1);
}