SerLCD 2.5 RX weirdness

Development Boards MicroMod
1

Here is a SerLCD issue I could not find anyone else posting about.

The display (2x16 display with serlcd integrated from SF) works fine connected to windows (w/ FTDI USB), and it works fine connected to my uC (jennic 5139 zigbee/arm7). But it only works w/ the uC if I leave the RX line disconnected until the SerLcd has been powered. If my uC’s rx line is connected from the start I get garbage (the correct amount of garbage, just not the correct characters).

If I power them both up with the RX disconnected then connect it works fine, if I reset the uC at this point everything runs as expected. If I hold the uC in reset until the serLCD has gone past the splash then let the uC boot … more garbage.

The only way I seem to not get garbage is if the RX is disconnected until power has been applied to the serLCD then the thing works great. With the uC connected to a terminal program I see no initial garbage during power cycling and I am not initializing the uart until well after the serlcd splash screen (2 second wait before bringing the uart up and attempting to send to the serlcd).

Any ideas would be seriously appreciated.

Aaron

2

Suspect that your uC is generating “some” output upon or shortly after power up - which passes thru to the ser Lcd’s input buffer. (this output may or may not be a full character - if you are monitoring the uC’s serial output with a terminal program you will not detect (not display) these incomplete outputs)

If you have a storage scope - or a simple shift register IC - you can monitor the serial output line upon power up. Guarantee that “illegal” activity is occuring.

Cure:

a) “open” the uC to ser Lcd data line until your uC has come out of reset and stabilized

b) “clamp” the uC serial output upon reset and until it has stabilized. This can be automated by using an R-C circuit which persists beyond the illegal event(s). (R-C clamps your output upon power-up - then releases)

Final note - this may indicate a faulty (too long) reset time w/your uC. Perhaps if you “speed” the uC’s reset - the illegal output may be prevented or may occur early enough that the SF uC is unaffected.