Thanks for the reply, will look at it when I get home.
I know the data pins are right because my board design has 8 LEDs on that port and you can see GLCDdiag turning them on in sequences.
It has to be the control lines or software!
It is unlikely to be software.
There has never been any issues with the low level i/o in glcd.
(Even as far back as the early betas 2 years ago)
The low level logic and Arduino pin mapping code is the same no matter which AVR processor is used.
There have been a few issues when people have tried to add their own
pin mappings for new processors, (like early on for the mega2560)
but that isn't an issue with the glcd software or with the low level i/o.
It is a pin mapping issue and is immediately obvious from looking at the diag output.
glcd does not use any Arduino code or core code to talk to the pins
so there isn't really anything in the way once the correct mapping is in place.
It still could be a data wiring issue. Say if the glcd is mis identified
and the wrong glcd pinout is used. Then while the glcd software is using the correct
pins on the AVR for the glcd data lines, the AVR pins are not connected to
to the proper pins on the glcd.
A terribly mis-wired contrast pot can also cause problems.
In 2+ years I've only seen two cases where the problem wasn't
a wiring issue. In those cases, it was bad glcd modules.
But both of those bad glcds were actually do to miswiring.
One was due to mis-wiring power pins, and the other by mis-wiring the pot.
Common causes of mis wiring are incorrect glcd pinout (using wrong data sheet).
mis reading the pins on the Arduino board - common on Arduino mega boards.
getting the glcd pins backwards. (Mis identifying pin 1).
Occasionally people get RST and RS confused so they end up hooking
up the DI pin to the glcd RESET pin and tying RS to Arduino RESET, or some other AVR pin.
Occasionally people mis wire glcd RST (reset line) and tie it to gnd rather than VCC
which holds the glcd in reset.