1
\$\begingroup\$

I am using a PC2002LRU-BWB-H-Q LCD with a STM32F4 micro and is powered through a TMP10424. There is also some 3V3 and 5V modules to. The problem is that the LCD is displayed fine for over days and then suddenly it stops to display. This may be down to power surges and thought the MCU was hanging. I added a watchdog to reset the MCU if it did hang.

The MCU seems to be fine because there is data coming from the UART and some Led's are toggling as they should but noting on the LCD. There is Light on it just no characters.

Also, I did notice that if I was probing the UART that it stopped displaying characters so it could be some sort of grounding issue, but the micro which is probably more sensitive is fine. I have 2 units set up so its not this particular LCD, the other one also stops displaying characters.

Is this a common problem with anyone?

LCD Interface: enter image description here

Thanks.

\$\endgroup\$
1
\$\begingroup\$

Not really a common problem. But the problem is that the display is used in write-only mode, so you can't read the status of it. What's worse is that 4-bit mode is in use, so any glitch on E wire will make the display to receive wildy different command and data bytes than expected, as the high/low nibbles are mixed. What might solve this is that periodically, like every second or every time the screen needs to be redrawn, it is properly reinitialized again.

It is also possible that the MCU write timing is on the edge of what the display can work with, so sometimes it might might just not see a write properly.

\$\endgroup\$
  • \$\begingroup\$ The re initialization does indeed fix the problem but does introduce a flicker. The pins are connected to the board via a joined back to back ribbon cable so this maybe a cause for some glitches. I am only updating every second or so that is way 4 bits are used. I may change to be read and write. Can useful data be read from the device? \$\endgroup\$ – MXG123 Apr 25 at 7:16
  • \$\begingroup\$ Flicker depends on how you initialize it, so only initialize the bus to consistent state, and rewrite the characters. At least the busy bit can be read to know when it is ready to receive next data or command. Otherwise worst case time delays are always needed. At the same time you could also check if the address register contains what you expect, to determine if there were glitches during the update. \$\endgroup\$ – Justme Apr 25 at 9:50
  • \$\begingroup\$ When initialized the screen is erased and then re-written, this causes the flicker. Unless it is possible to initialize it while holding the existing screen. Is this possible? \$\endgroup\$ – MXG123 Apr 25 at 12:59
  • \$\begingroup\$ Well, why do you erase it then if it causes flicker? Why not just write the stuff that was already there without erasing it first? \$\endgroup\$ – Justme Apr 25 at 17:44
  • \$\begingroup\$ I'm not deliberately erasing it. The initialize method (provided by compiler) does. By initializing it brings it back to its default value so it must be re-written. Now I haven't written my own initialization procedure but I would assume it may involve resetting and/or clearing registers and thus would clear the screen. Am I not correct in this assumption? \$\endgroup\$ – MXG123 Apr 26 at 7:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.