ILI9341 2.4" Waveshare Screen and Backlight Variances

[phillmj]

Hi, I'm using the fantastic TFT_eSPI library v2.5.0 with a Waveshare 2.4" ILI9341 screen

When I write to the screen, the backlight goes up and down and makes other previously drawn elements appear brighter as I'm
writing to the screen. The application is a midi fader, so when I drag faders and draw graphics to the screen, the backlight gets brighter in other parts of the screen I'm not drawing to.

This creates a flickery and undesirable effect.

I am using the same code base with a smaller 2.0" Waveshare screen with the TFT_eSPI library - literally same code except different driver - and this never happens.

I'm not at all certain this is a library issue, but somehow the backlight is varying on the 2.4" screen and I'm not sure how to stabilize it.

Does anyone have an idea how to go about troubleshooting and fixing this issue? Do I need to add a capacitor to the LCD brightness pin? Or should I use 5V power to the screen (screen uses 3.3 or 5v)? I'm at a loss as to how to proceed.

Thanks for any insights,

Mike

[Bodmer]

The brightness change is due to power voltage fluctuations caused by the higher processor and display operating current during the data transfer process.
Despite indications in the display Wiki that it will work from 5V, that is not advisable since the board has NO 5V regulator, the transistor is there to turn on/off the back-light.
White LEDs need about 3V, this leaves a tiny voltage across the current control resistor, so small supply voltage variations change the back-light LED brightness significantly.

Options:

1. I am guessing you are using the processor 3v3 regulator that is powered from 5V. This has to supply the display and processor. An iadditional 5v to 3.3v regulator could be used to provide an independent supply to the display.
2. Add 3.3v supply decoupling, maybe 470uF. However that may only reduce flicker.
3. Reduce the processor clock speed and/or the SPI clock speed to reduce the peak current demands.

If the processor has WiFi, then using that will also cause significant flicker due to the transient power demands.

As you have surmised this is a hardware level problem rather than the library.

[phillmj]

Thanks for a wealth of suggestions!

I will follow up on them and report back.

I am going to start by adding a capacitor only, as I don't want to have to create an additional power supply for the unit if possible.

Strangely, the screen gets brighter when the faders are moved, not dimmer, which is completely counterintuitive.

Thanks again,

Mike

[phillmj]

Quick question, I'm using a Teensy 4.0, do you think I could use the 5V output pin from the Teensy and send that to a voltage regulator5V down to 3.3V on a breakout board, and then feed that into the LCD input? Or would I have to intercept the 5V in from the USB directly? Asking because it would be much easier to pull off the Teensy pin rather than figure out how to have two USB micro B connectors on the breakout board.

Thanks for your expertise; you never cease to amaze.

All the best,

Mike

[Bodmer]

Yes, you could use the 5V for the regulator. It will be derived from the USB power.

[phillmj]

OK that's fantastic! Thanks for the support and wisdom.

That will actually be pretty easy to do, as I'll just update the PCB to include a 3.3V linear regulator and use the 5V to power it.

I'll first test it out on breadboard of course to make sure I've got it working.

I will report back here again as this progresses, to document the results.

Thanks so much!!

Mike

[phillmj]

Hi Mr. Bodmer, I have added a 5V to 3V regulator with 1uF caps on input/output voltage per the data sheet, and I also added 10uF and 100nF caps on input/output as well (not specified in the data sheet). The screen is now powered by the regulator independent of the Teensy 3.3V output pin.

This has done nothing to eliminate the problem unfortunately. Reducing SPI frequency doesn't seem to have an affect. Is there a way to know what SPI frequency is optimal? This screen works all the way up to 80000000, but even down to 27 it is the same with the flicker.

I am nervous about adding a 470uF cap since the USB spec says not to use over 10uF (if I understood it correctly). But I'm pretty sure the LDO voltage regulator is working, so I'm not sure why the issue remains.

I am wondering if the Teensy backlight pin could be fluctuating on screen writes? Its an analog pin and I'm using the following line to set the backlight level

analogWrite(BackLightPin, BackLightLevel);

Could this pin be experiencing voltage fluctuations on writes, and if so, can you think of any way to eliminate this? Add a cap on the backlight output? (by the way, of course I am not changing this line of code when the flickering is happening).

The really odd thing here is this exact same code works perfectly on a slightly smaller 2.0" waveshare screen, even without the LDO regulator.

I reached out to Waveshare and this was their response:

Hello
Thank you for choosing our products
It may be caused by unstable power supply. What is the maximum current of your 3.3V output?
Please try disconnecting the BL pin to see if it still flashes
Best regards
Rain

I did try disconnecting the backlight pin and the issue remains.

This is a puzzler. Do you have any other tricks up your sleeve? It's for customers and I'd love to find a way to get rid of the flicker.

Thanks for your time Mr. Bodmer.

Mike

[Bodmer]

I suspect there are still voltage variations. It is a case of finding the root cause.

First check it is actually the backlight LEDs that are flickering, it may be the LCD pixel drive as the percentage light passed through each pixel is also achieved by voltage variation.

If you have an oscilloscope you can look for AC variations on the supply. Ideally you want differential probes or the unit-under-test to be isolated from ground, but the voltage variations may be obvious without that.

Do you have good (multiple wire very low resistance and inductance) 0V connections between all components to prevent ground bounce causing voltage fluctuations?

Adding 470uF temporarily is unlikely to cause an issue, especially if it is ont the 3.3V output of the regulator. A temporary test would at least give an idea of the root cause.

The disconnect of the BL control would eliminate PWM mark space changes that would modulate the backlight brightness.

As noted earlier the voltage across a white LED is so close to 3.3V that small supply voltage variations can have a significant effect. Some boards use 5V for the LED current drive so small voltage changes affect the brightness to a lesser degree. It might be possible to modify the board and increase the current limit resistor or find a board from another supplier that is less susceptible to supply modulation.

[phillmj]

Hi Mr. Bodmer, thank you so much for your helpful reply.

I tried the 470uF cap from 3.3V supply to ground at the input to the LCD VCC, and unfortunately this did not change anything.

The PCB board has a ground plane, so there shouldn't be any issue with variations in ground. Strangely, again, the 2.0" screen using the exact same board has no issues.

I did try disconnecting the backlight from the Teensy, and again the problem persists. At least we know it's not due to backlight output issues.

I don't have an oscilloscope so I can't chase down your other suggestion.

It may be down to finding a different screen at this point. Waveshare support is asking for proof so I'm going to make a video of the issue, which I will also link to here after I make it. But I don't think they will be able to fix this, especially if it's a hardware issue.

It may end up being a good thing, as this 2.4" screen isn't as bright as their 2.0" screen, and the colors seem a bit duller/muted compared to the 2.0" screen as well (same code! Your awesome library!).

If you have any suggestions for awesome 2.4" LCDs I would be grateful.

Thanks again, and I'll post back with a link to a video showing the issue.

Best,

Mike