ST7920 128x64 display _sometimes_ flickers, any solution? - Page 1
Forum section: electronics / projects

author: Professzore
author_rank: Contributor
timestamp: July 07, 2023, 12:28:45 pm
content: Hi,I'm working on this pre-production project for over a year. There are many (10-ish) prototypes are out there for stress testing without any significant issues except one repeating problem. This is clearly visible in this youtube video.https://youtu.be/hHu6QfjmDnwTech details:MCU: STM32F411REdisplay: 128×64 pixel, ST7920 controller, serial line (CLOCK, DATA, CS, this last has no change in the process, fixed to ground through the MCU),display initialized on 10 MHz clock, but changing this value in code doesn't make any change in behaviourProblem:right after the initial power-up, the display redraws itself completely after each write ("refresh") cycle. This behavior is visible in the video (middle three power-ups). In every other case, the display shows only the regular (known and acceptable) flickering.This behavior is random, there is no connection either to the manufactured board, the display, the power chain, or even the MCU. The code is the very same on each MCU. Tough, there are prototypes, where this happens a bit more often, meanwhile some others produce this once or twice in every 20 power-ups.Debugging procedures and findings:serial lines are in sync, there is no significant jitter, phase-shift between clock and data, or any other problem (at least as far as I can see it with my scope).Start-up procedures (delays) are all within the specs of ST7920.All power lines are within specs.As far as I can see, all data transfers are the same from the very beginning of the start-up procedure, whether the screen is in normal or in flickering "mode". In other words: there is no "missing" or "additional" packets during the initialization of the display.Flicker is correlated ("synced") with the screen write cycles, which take into action every 200-ish ms.Once started with the flickering, it can't be fixed by either: resetting the LCD, resetting the MCU, or de-powering the LCD.The only "trustable" solution to the problem is (sometimes over 10) power cycles.Start-up sequencing with an actively switched LCD power line need some parts and a reworked PCB, but all tests on prototype PCBs with this setup failed.Any hints or suggestions are welcome. If you have any questions or request to make specific measurements (as far as I can make it with a Rigol MSO1104), I'm happy to make it.I highly appreciate any effort to help me.Yours sincerely,Tamas

author: Andy Watson
author_rank: Super Contributor
timestamp: July 07, 2023, 01:12:48 pm
content: Is the back-light powered with pure DC, or is it pulsed via an inverter or such?Quote from: Professzore on July 07, 2023, 12:28:45 pmAs an experiment, could you push "write cycles" to occur on a more irregular basis?

author: Professzore
author_rank: Contributor
timestamp: July 07, 2023, 01:56:36 pm
content: Hi,Thanks for replying!Blacklight is full direct DC 5V.The screen refresh is changing, this "idle" state isabout200 ms, but in other working states it is between 10 Hz and 2 Hz, or even 0 Hz (no refresh, see here:https://youtu.be/0izQZ-ZfLVA).My main concerns are:if this is a hardware error, it must exist on every, or near every model,if this is a PCB design issue, it must be fixed or not exist on many former prototype boards,if this is a software problem, it must exist on more models and should be visible on the serial data or in the initialization sequence,

author: coromonadalix
author_rank: Super Contributor
timestamp: July 07, 2023, 05:16:59 pm
content: 2 times ive seen this, some dc-dc conveter on the lcd / tft board to give a nergative backplane "drive" one lcd needed an -23 vdc ??and or the said backlight invertercapacitor where the root cause ...my 2 cents

author: DavidAlfa
author_rank: Super Contributor
timestamp: July 07, 2023, 05:58:19 pm
content: The ceramic capacitor will not be happy at -23V, will degrade quickly and lose a lot of capacitance, easily -70%.This could be the root of the problem, find that cap and resolder it, temperatures over 125°C will "reset" the dielectric material, recovering most of the original capacitance.If the problem persists, try resoldering the remaining ceramic caps.Though it could be a problem in the initialization, maybe too fast faster power on, requiring a larhee of delay for the power to become stable.Does reinitalizing the display (Without removing the power or resetting the mcu) fix the problem?Try adding something like Delay_ms(500) at the startup, before the mcu inits anything.

author: Professzore
author_rank: Contributor
timestamp: July 07, 2023, 06:54:58 pm
content: Hi,Thanks for the reply.This is the actual product.https://createc3d.com/en/electronics/371-buy-lcd-full-graphic-smart-controller-price-offer.html#box-questionsAnd this is a "salvaged" schematic:http://julesgilson.com/wp-content/uploads/2017/07/schematic1.jpgThis is the closest reproduction I could find. Unfortunately, this part is "mandatory" as the customer ordered over a hundred pieces. That's a pity, but I must deal with it until version 2.0At this point, I barely able to convert your ideas into useful scenario (my fault).

author: Professzore
author_rank: Contributor
timestamp: July 07, 2023, 07:28:48 pm
content: Hi,Thanks for the reply!Quote from: DavidAlfa onTodayat 05:58:19 pmSee my other answer with some other information (links) about the actual product. This is astupidsolution to this goal, though, whatever my price is, it must be fixed.Now there is about 200 ms delay between power-up and the first data sent to the LCD. Anyway, one line of delay isn't a big deal. I'll try it tomorrow. :-)I couldn't find any workaround which works. I tried re-initialization too. Whatever I do, if the display starts with this "flickering", the phenomenon remains active until thenthpower cycle, where 1 <n< 15.

author: DavidAlfa
author_rank: Super Contributor
timestamp: July 07, 2023, 08:26:18 pm
content: Hmm that display is supposed to be powered with 5V?Perhabs some issue with the 3.3V logic level from the stm32?

author: Professzore
author_rank: Contributor
timestamp: July 08, 2023, 09:26:07 am
content: Hi,Findings for tomorrow morning:LCD logic is indeed has a 3.3 V source. I do not have any idea why did they use a resistor to make it, despite the dedicated 3.3 V converter is about 3 cm away on the same board,Though, 3.3 rail is relatively clear.5 V rail has a terrible 25 kHz-ish switching noise, this was eliminated with a 10 nF ceramic, and as a resultno change in flickering.Next step: power-up sequencing by software, I'll check if a +500 ms delay in the boot-up process may fix this issue.As a last chance, I'll make some slight high-frequency filtering on the serial line.I have no other idea.

author: Buriedcode
author_rank: Super Contributor
timestamp: July 09, 2023, 01:34:33 am
content: The schematic is incorrect - you have the contrast pot on the backlight LED anode. I'm assuming that you've made a mistake there but it doesn't build confidence that any other part of the schematic is correct.Where is the schematic from your CAD PCB software?It looks like brown-out to me, but I have seen older displays - both graphic and character - that do behave weirdly when certain timings are violated, or when there are undocumented requirements like small delays between de-asserting/asserting chip select.Honestly, we need more info - preferably:- A decent schematic - including regulators and cap values used.- Code - at the bare minimum the init and write routines for the display.- Layout, even if its just the display and MCU.Whilst power cycles shouldn't in any way "fix" a software problem, if timings are close to the spec limits for the display then variations in the harware could push it over a threshold meaning its a multitude of things that conspire to create the problem = a bigger headache.Simple debugging of the firmware - such as a basic "push button that cycles through a sequence of routines commonly used" - ie: first press, init, second press, write on a line, third press, write next line etc.. THen you could combine these in one press for speed to see if it needs a delay between writes. We're pretty much blind here though.

author: amyk
author_rank: Super Contributor
timestamp: July 09, 2023, 02:38:40 am
content: I'd start with slowing down the timing to "near human" speeds - there's no minimum frequency with these displays. If it's still happening, I'd check whether the internal oscillator of the controller is somehow intermittently starting up at a much lower frequency. If you're checking the busy flag after each operation as you should, this would also manifest as operations taking much longer than they usually do. A look at the datasheet shows that frequency decreases as Rosc increases, so a bad connection of the Rosc could cause the symptoms shown.

author: Professzore
author_rank: Contributor
timestamp: July 09, 2023, 02:08:10 pm
content: Hi,Thanks for replying.As I mentioned before, this is a “use it for all costs” display. Ordered in a huge quantity, and whatever it's not suitable for our needs, it must be used for this project. First, it has no official documentation at all. In other words: it's the worst from the “junkyard”.In detail to answer your questions.1. This board is built with two main parts, a “piggyback” board (RepRap…bla-bla), and a rather common 128x64 ST7920 display board (also a module). See the link in an earlier post.2. The whole module has other parts: an SD card reader, a reset button, a rotary encoder with a button function, and a buzzer. None of them are used.3. The relevant circuitry on the board part is shown at this link:https://www.dropbox.com/s/6oamjp27xuguz4s/st7920_display.pdf?dl=0(or maybe the attachment also visible)" alt="" class="bbc_img" />4.There are no additional parts on this board, though,there is a 100 nF ceramic cap on the 5V rail on the main board next to the 10-pin IDC header which is used to connect the display to the main board. +5V (at the power pins) seems to be way within specs in any time domain.In the recent hours I dismantled one unit, so now I have a barebone display with the necessary pins cleared. I also have a “prototype” main board, so I can make a different setup with much more control over the hardware part. I'm not sure if this will bring me any closer to the solution, but I'll make a try.Debugging.I'm done with this proceduremonths ago. The results are the same, even when the code is just an init, a “Hello World”, and “refresh when a button is pressed”.On the software side, I'll try:lower freq for the serial line (tried about 6 months ago without any change),I'll try to put some delays when I write to the screen, by the way, the current refresh rate is about 5 Hz now,There is no feedback from the display to check if the refresh procedure is done or not, so the whole debugging will be a trial-and-error game.Without question, this part will be way more expensive than buying a comparable load of quality displays and redesigning the main board and the code to work with.I'll back with more details and some more answers to your questions.

author: Professzore
author_rank: Contributor
timestamp: July 09, 2023, 02:50:22 pm
content: Hi,Since then (after dismantling a board), I found that the display is indeed designed to be powered with +5 V.ST7920 input high threshold is 0.7 V to VDD, so the output high of about 3.3 V from STM32 shall be enough --I wonder....

author: DavidAlfa
author_rank: Super Contributor
timestamp: July 09, 2023, 02:57:42 pm
content: I see no reason why the LCD wouldn't work at 3.3V, ST7920 datasheet states a working voltage of 2.7-5.5V.But you must power the display at the same voltage as the logic level, otherwise 0.7*5V=3.5V, 3.3V is not within specs, plus a 10MHz signal will be pretty noisy.I guess you're not using the SD card, if so then you might need to bypass the LDO if using 3.3V, some LDOs are crap and will drop way too much voltage, outputting <3V from 3.3V input.

author: Professzore
author_rank: Contributor
timestamp: July 09, 2023, 07:13:40 pm
content: Quote from: DavidAlfa on July 09, 2023, 02:57:42 pmWith the current setup, I can easily switch to the 3.3 V rail of MCU. I'll check the necessary power and will make some changes to meet the specs on both sides (MCU and display).Backlight needs 5 V, but that's not a problem.I highly appreciate all your efforts. Thank you very much!

author: Professzore
author_rank: Contributor
timestamp: July 11, 2023, 07:27:04 pm
content: Hi,After some further investigation (at this time, mostly from firmware). Here are the findings:The display on its own works as it worked with the piggyback mount. 5 V needed. Logic levels are just fine as they come out of the MCU.Lower SPI frequency doesn't make any change until the refresh rate is higher than the data transfer time. Reducing the refresh rate (even under 1 Hz) with a very low SPI frequency produces the very same flickering problem. Not less often, not more often than statistically observed.A change of delay from the initialization to the very first write session to the LCD doesn't make any change. As if I reset the display before the first write. If it powers up with the wrong "flashy" behavior, it remains the same.I'll try to find an alternative init method...

author: eugene
author_rank: Frequent Contributor
timestamp: July 12, 2023, 02:45:40 pm
content: When I see something like this my first guess is that at power up the supply voltage drops causing the system reset, which allows the supply to recover, and then reset again, and then recover.... over and over.If that is the problem, then sequencing start up might help. If you have switching regulators they may be simply under rated. Could always try the brute force approach of adding lots of capacitance.

author: Professzore
author_rank: Contributor
timestamp: July 12, 2023, 07:11:13 pm
content: Seems obvious, but solved. The overall current draw of the whole setup isunder 20 mA@ 5 V,including the blacklight.I have experience with this phenomenon with "clever" displays, more likely cheap Chinese garbage. 500 + mA current bursts and so on...

author: DavidAlfa
author_rank: Super Contributor
timestamp: July 12, 2023, 08:33:53 pm
content: More like poor vdd decoupling then