0
\$\begingroup\$

16x2 LCD operating in 4-bit mode. At first, I tried initializing the LCD in 4-bit mode using software. Did not work. After repeated tries however, LCD started working. But for some reason I had to reset the microcontroller 2 or 3 times for it to properly function. On the first reset, it shows garbled values, but on repeated resets, it started displaying properly. Then I switched the project to STM32F030R8 and again the LCD wouldn't work. Sometimes when I connect and disconnect the ground jumper it goes into 4 bit mode and displays some random things. When the power is turned on and off, it'll be back to square one.

\$\endgroup\$

closed as unclear what you're asking by berendi, Elliot Alderson, Finbarr, RoyC, Chris Stratton Mar 31 at 17:08

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

1
\$\begingroup\$

If you reset software without turning off power, the display can be in one of the following states:

(State1) 8-bit mode
(State2) 4-bit mode, waiting for the first set of 4 bits
(State3) 4-bit mode, waiting for the second set of 4 bits

There's no way for you to know in which state the display is, but you can always set it into 8-bit mode. Set D7-D4 pins to 0b0011 and toggle the enable pin three times. This ensures that the display is in 8-bit mode. You can now switch to 4-bit mode by setting D7-D4 pins to 0b0010 and toggling enable pin.

More details here: Hitachi HD44780 LCD controller

\$\endgroup\$
0
\$\begingroup\$

Problems such as you observe can occur due to failure to initialise some part of the system. This could be the LCD driver, as @user930473 susggests , but could also be the microcontroller.

When your code starts, does it initialise ALL used registers and memory locations to known states? For example, RAM locations MAY usually contain $00 or $FF at startup, but if this is assumed and is not specified by the datasheet then if your code depends on a "usual" value it may fail.

In my experience "boundary conditions" are the cause of a large proportion of failures or of 'strange' operation. Examples include (with varying degrees of relevance to "boundary conditions") but are certainly not limited to failure to initalise memory locations, incorrect assumptions about loop counts or loop entry conditions or loop termination conditions, counter wrap-around effects, stack over and underflow, .... .

But, start on checking initialisation of all required processor and LCD registers and memory and you have a good chance of finding your problem.

\$\endgroup\$

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