16x2 LCD Pi Plate -- No Display

[fidelite]

Good morning, I recently purchased a blue LCD (Much like this one -- http://www.adafruit.com/products/1110) but with the buttons slightly different than the picture.

It's a 2nd generation rpi, so I've changed all instances of busnum to 1 for all files.
As it's using the MCP23017-E/SP IC, I've also increased the num_gpios = 16 in the Adafruit_MCP230xx.py, and set the busnum = 1
mcp = Adafruit_MCP230XX(address = 0x20, num_gpios = 16, busnum = 1)

Troubleshooting:
- The buttons appear to work as expected:
If I use the button test script from here: viewtopic.php?f=50&t=36800 I can see that the buttons are working as expected.

- The i2cdetect can find the device @ the correct address:
# sudo i2cdetect -y 1

20: 20 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

- Adjusting the contrast pot seems to have an effect on the faded boxes in the background. (Could be mistaken here)

- running LCDTest seems to hang, and when I hit control + C I get:
Traceback (most recent call last):
File "./LCDtest.py", line 55, in <module>
if (lcd.buttonPressed(lcd.RIGHT)):
File "/home/pi/Adafruit-Raspberry-Pi-Python-Code/Adafruit_CharLCDPlate/Adafruit_CharLCDPlate.py", line 261, in buttonPressed
return not self.mcp.input(buttonname)
File "/home/pi/Adafruit-Raspberry-Pi-Python-Code/Adafruit_CharLCDPlate/Adafruit_MCP230xx.py", line 122, in input
value = self.i2c.readU16(MCP23017_GPIOA)
File "/home/pi/Adafruit-Raspberry-Pi-Python-Code/Adafruit_CharLCDPlate/Adafruit_I2C.py", line 107, in readU16
result = (hibyte << + self.bus.read_byte_data(self.address, reg+1)

- Running Adafruit_CharLCDPlate.py has a similar output:
sudo python Adafruit_CharLCDPlate.py
^CTraceback (most recent call last):
File "Adafruit_CharLCDPlate.py", line 274, in <module>
if (lcd.buttonPressed(lcd.UP)):
File "Adafruit_CharLCDPlate.py", line 261, in buttonPressed
return not self.mcp.input(buttonname)
File "/home/pi/Adafruit-Raspberry-Pi-Python-Code/Adafruit_CharLCDPlate/Adafruit_MCP230xx.py", line 122, in input
value = self.i2c.readU16(MCP23017_GPIOA)
File "/home/pi/Adafruit-Raspberry-Pi-Python-Code/Adafruit_CharLCDPlate/Adafruit_I2C.py", line 106, in readU16
hibyte = self.bus.read_byte_data(self.address, reg)
KeyboardInterrupt

When I run either of these scripts, I'm not sure if it's supposed to return to the command line, but it does not. Just kind of sits there, pushing the buttons on the LCD (All of them) Do nothing to return it to a command prompt.

Suggestions?

[adafruit_support_bill]

(Much like this one -- http://www.adafruit.com/products/1110) but with the buttons slightly different than the picture.

So this is not an Adafruit Pi-Plate? You should contact the vendor or manufacturer for technical assistance.

[fidelite]

No, as stated in the original message, the one I got from Adafruit has a different button layout than the one depicted.

This says "Adafruit i2c 16x2 RGB LCD Pi Plate" on the top of the back card with the adafruit logo on it.

Additionally, I've harvested some of the LCDtest script and trimmed it down to just this:

#!/usr/bin/python

from time import sleep
from Adafruit_I2C import Adafruit_I2C
from Adafruit_MCP230xx import Adafruit_MCP230XX
from Adafruit_CharLCDPlate import Adafruit_CharLCDPlate

import smbus

# initialize the LCD plate
# use busnum = 0 for raspi version 1 (256MB) and busnum = 1 for version 2
lcd = Adafruit_CharLCDPlate(busnum = 1)

# clear display
lcd.clear()
# hello!

Which runs, but doesn't appear to do anything (Rather than before where it would appear to hang, presumably because of the keypad inputs, which we know work independently)

Is there a way to increase verbosity of logging perhaps?

Also, I'm not sure if the screen should be backlit as soon as it has power or not, but right now, it looks like it's not even getting power, but I can't be sure.

Cheers!

[adafruit_support_bill]

Sorry for the misunderstanding. I see now there was a recent re-design that changed the button locations.

The standard Adafruit_CharLCDPlate.py script will change the backlight colors when you press the buttons. but since you have a monochrome (white) backlight, it uses only hte "red" pin for backlight control and will only respond to color selections that have red in them. Using that sketch, the left button should turn the backlight on for you.

If that doesn't work, post photos of the front & back of the Pi-Plate and we'll take a look!

[fidelite]

OK, running the LCDTest.py and hitting left does nothing. Let me do some checks with a multi-meter and see if all the connections are good.

Many thanks for the follow up, I'll try and get some pics tonight if I can't correct it myself.

Cheers!

[fidelite]

Progress (kinda)

Seems I had a bad link on the second 5V connection, corrected, and now the screen turns on, but all I see are boxes. The pot appears to work and control the contrast, and the buttons appear to work to enable / disable the backlight.

I can confirm that the 5v, ground, and SDA and SCL are connected to the appropriate pins on the MCP28017 controller by using the following chart:
http://farm8.staticflickr.com/7219/7320 ... e97c_z.jpg

Additionally, if I look at this http://learn.adafruit.com/system/assets ... 1345326108 we can see the pinouts for the actual LCD, and these don't match up exactly to what I'm getting from the MCP (continuity wise)

LCD: DB4 DB5 DB6 DB7
MCP: GBP3 GBP4 GBP5 GBP6 (so, there doesn't appear to be anything connected to GBP7?)

[adafruit_support_bill]

That diagram looks like it is for connecting an LCD directly to the Pi GPIO pins. It won't help you here. The Pi-Plate uses an I2C port expander to communicate with the display.

[fidelite]

So what should I do?

#sudo i2cdump -y 1 0x20
No size specified (using byte-data access)
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: 3f 00 00 00 00 00 00 00 00 00 00 00 1f 00 00 00 ?...........?...
10: 00 00 9f 95 9f 95 00 00 00 00 00 00 00 00 00 00 ..????..........
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

[adafruit_support_bill]

Post photos of the front and back and we'll take a look.

[fidelite]

Sure, pics here:

Powered on (with the squares)


Front View


Rear view

[adafruit_support_bill]

A lot of your joints are only partially soldered. Make sure that the solder flows well on to both the pins and the surrounding pads.
http://learn.adafruit.com/adafruit-guid ... n-problems

[fidelite]

I'll take another stab at it tonight, but is there a way to verify WHICH pins require re-soldering?

As I mentioned before, when I plug a pin into the header, and then trace that to the MCP or LCD panel, and run a multi-meter I can see that there certainly appears to be connectivity between the start and end pin, now, I preface this with I'm not electrically inclined, so I'm not sure if the presence of continuity implies a proper connection, or, if there are other factors to consider, and more importantly, if there is a way to test this condition, also, is this specific to only components like the MCP (Where there can be connectivity, but that does not imply a "good" connection).

For instance, we know that more than 1/2 of the pins on the MCP aren't in use, so does that mean that the connections on that part don't need to be perfect? (I'm very OCD, so eventually I'll fix all, but I'd like to know which ones to focus on first) If not, why not if these aren't being connected to anything anywhere (For my own learning mostly)

My apologies if these are super n00b questions, I have people around me who are electrically inclined (or, who claim to be) and I would like to know the "proper" method (if any) to trace this down with a bit more precision than just to have to resolder everything that looks bad (Not that, that's not a viable action plan, just VERY time consuming for someone like me with less than stellar soldering skills)

Many thanks for your time and input.

Cheers!

[adafruit_support_bill]

Intermittent connections often become conductive when you poke them with a meter probe. So that is not a reliable indication of a good joint. Believe it or not, the gold standard for mil-spec, medical and other critical circuits is stil visual inspection. If it doesn't look smooth and shiny and flow well onto both the pin and the pad it will get rejected or sent back for rework.

As for which ones to focus on, it will probably take less time to retouch them all than to read the chip printouts and schematic. But you will want to focus on the i2c pins (A4 & A5) and the 4 data lines going from the chip to the LCD.

True, you don't need to worry about unused pins - unless they are tied to ground or VCC. But be sure to check both sides of the board because not all traces are on the solder side. With multi-layer boards, the best bet is to assume everything is connected.

[fidelite]

Redid what I could, and still no dice.

Thanks for the helpful info, and not to contest your many years of experience, but in my testing, it *appears* that the data to be getting to where it's going, and here's why I say that:

Inside the Adafruit_I2C.py file I set the debug flag to true, which results in the following when I execute the python script. Additionally, the squares or boxes on the screen may indicate that the screen has yet to be initialized. The screen seems to "respond" to the screen.clear() command in python. (Not sure what functions those are, but my point is, it appears to be responding to commands, and I'm not sure what the difference is between a clear and the display of a character)

The output below seems to indicate that we do have proper communication to the MCP:

I2C: Wrote 0xA4 to register 0x13
I2C: Device 0x20 returned 0xA4 from reg 0x15

Further analysis seems to indicate that you are using the following registers on the MCP (0x20):
0x00 0x01 0x0C 0x0D
0x12 0x13

Button pushes seem to be propagated from the 0x12 and 0x13 registers, while LCD commands appear to only go through 0x13. Based on the fact that button responses have always worked, this would seem to indicate that we are able to read and write from both 0x12 and 0x13, however, this does not prove that initialization has worked. (if it's even required I don't know) based on all the data I have gathered, it doesn't appear to be an issue with the flow of data to the MCP (and by virtue of the screen.clear() the LCD). All of this said, I'm a troubleshooter, not an electrical person. Every test I have done seems to indicate that data appears to be getting where it's supposed to go. I don't want to debug all of your python code, so if there's a way to do it using just the i2c commands (and it appears that it is) and you can say "Set register X to Y, see how your getting Z instead of 1?" then I can solder each point, and retest the register set, and once I get the value I'm looking for, I can move forward, but without that, I'm basically spending hours soldering and praying that one of the pins I "fixed" works.

There seems to be some steps online to interface with the MCP, and other instructions on how to talk to the LCD, but not both the MCP and the LCD.

Some of the solder points I can't get to really mostly because I'd literally have to disassemble the whole thing to reapply the solder, and every logic test I've done
seems to indicate otherwise. Here's my thing, I can solder this thing until the cows come home, but based on all of my testing, it probably won't do any good, and each day that passes is another day outside of my 30 days to return the product, and another day my project is delayed.

[adafruit_support_bill]

Based on what you describe, the I2C communication with the port expander chip is working fine. You have control of the backlights and some sort of communication with the display logic. I'd look closely at the RS, RW and D4-D7 pins on the LCD. In your photos, the solder joints on the top-side of the display all had minimal wetting on the pin & pad.