I'm using a 16x2 LCD for a project on STM32F030R8. I wrote a library for interfacing and everything was working fine until recently. It displays garbled junk values in between operations, especially when I press a button and it has to change DRAM contents. It somehow started when my code size grew a lot or when I increased the MCU clock to 48 MHz. So far I'm clueless about what's causing this. It displays wrong characters on initialization after power down too.

EDIT: On my board, there is an interrupt service to update seven segment displays every 10 ms. Turning that off solves the problem. It might be that the interrupt is getting called in between LCD updates. Any idea how to solve this?

  • \$\begingroup\$ How are you interfacing to the LCD? SPI? I2C? \$\endgroup\$ – Ron Beyer May 2 at 4:34
  • \$\begingroup\$ Nah, just vanilla GPIO. \$\endgroup\$ – sixter May 2 at 5:08
  • 1
    \$\begingroup\$ I have to assume you mean a HD44780 compatible display? Post the code and schematics or we have little to work with. \$\endgroup\$ – Justme May 2 at 5:48
  • \$\begingroup\$ Yes, that is so. \$\endgroup\$ – sixter May 2 at 9:20
  • 3
    \$\begingroup\$ With no code, and no schematic we're clueless too about why it doesn't work. How would you answer this question if someone asked it to you? \$\endgroup\$ – Colin May 2 at 10:38

If your 10ms refresh rate isn't critical, maybe disable the timer at the start of the LCD update routine and restart it after the LCD is updated? I'm sure the LCD finishes quickly enough that it won't make a noticeable difference, depending on how much of the LCD you need to update.


You say you upped the clock to 48MHz. Were you implementing any delays in your library? Some LCDs are quite slow and have minimum time requirements for some signal transitions.

Modifying the clock speed, especially increasing it, would likely have made those delays shorter and maybe now they are out of spec.

Code size probably has very little to do with it. Check the datasheet and make sure you are still within spec for your signals.

  • 1
    \$\begingroup\$ I don't think so. STM's HAL_Delay is pretty much clock-independent and besides I'm using large delays anyway. \$\endgroup\$ – sixter May 16 at 6:09

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.