Spurious pixel and lines using Bodmer's library Due on a HX8357B TFT

I am having challenges with an Arduino Due and a HX8357B 480 x 320 shield (originally for the Arduino Mega2560)

I have installed Bodmer’s library TFT_HX8357_Due version 0.26.0 and can run the demo’s - however the display show spurious pixel errors (different pixel errors on reset so I assume it is not the display that is failing on the pixels).

Also the “end” of the display have a gray’ish block of lines as if a screen fill had problems.

My device is a HX8357B and I User_Setup.h reflect this with:

#define HX8357B
//#define HX8357C
//#define ILI9481
//#define ILI9481_8BIT

I have reduced it to a small test with the following code (where I change the orientation and size value between each image taken - images attached to this posting):

#include <TFT_HX8357_Due.h>

TFT_HX8357_Due tft = TFT_HX8357_Due();

void setup(void) {
  tft.drawRect (0, 0, 479, 319, TFT_GREEN);

void loop() {
    tft.setCursor (100, 5);
    tft.print("Just Some Demo Text");

Does anyone have experience with this combination and what causes this?

Hi, there are two possible reasons for this. See the post here.

Note that vendors do not always quote the correct driver chip.


I have done some tests. You definitely have an ILI9481 based display.

If I run the HX8357B driver on a display with an ILI9481 fitted I get the exact same screen shots as in yout post.

If you select that option in User_Setup.h you will get a perfect display without those stray pixels.

Good luck with your project.

Thank you for your responce. Somehow I thought I had already tried that - but apparently I had not - because you were spot on.

Now I can continue making my XL-IR remote.


I don't think this is related as it appears to be solved but I noticed strange rendering of odd sized pictures with the associated library JPEGDecoder.

After months of playing with Ali Express 3.95" screens (Uno format and David's MCUFRIEND_kbv library) I am preparing for the arrival of a Mega format 3.95" screen. I expect this will use your HX8357B library? ? ?

Displaying a 220 X 165 picture I noticed corruption on the right hand side and on the bottom. First the RHS, 220 is NOT a multiple of the 16X16 MCU, there is 12 pixels left over which is 4 pixels short of the final MCU. There is a strip of 4 pixels that seem to be left over from the previous MCU. Ditto on the bottom (165 pixels), which is more noticeable as there is 5 pixels over, 11 pixels short of another row of MCUs.

I displayed the same 220X165 pictures on my Windows 10 desktop and they display correctly so the problem has to be a bug in the low level driver methods of JPEGDecoder?

Beyond your control?

I am not looking forward to reverting to HX8357B format coding from MCUFRIEND_kbv I hasten to add. :(

Edit: Sorry, using example TFT_draw_jpg_v4

MCUFRIEND_kbv and HX8357 libraries both use the Adafruit GFX methods. (In common with most other Arduino libraries)

Ok, there might be some minor differences with the low level hardware methods. You can either write a helper function or use a GLUE class that tidies up the minor differences.

Personally, I find the Adafruit methods far more intuitive than say the UTFT methods. I suggest that you choose one style and stick with it.


Sorry David, no offense intended.... I remember I had a lot of recoding to do when I went from UTFT to MCUFRIEND_kbv. I forgot that I had already done a lot of recoding to go from HX8357 to UTFT ;)

UTFT combined the setCursor and the draw.... commands and I adopted THAT format.

It was actually when using your library and JPEGDecoder when I found the corrupted RHS and bottom of pictures. I then confirmed the bug using the example TFT_draw_jpg_v4 :(

I started with .96" screens thru 2.2", 2.4", 2.8", 3.2", 3.5" to, finally, 3.95" screens and a FEW libraries along the way....

I had considered a 800x480 screen but doubt, even the Due, would be fast enough to drive an 800*480 screen? ? ? ?

I hope, when I pickup my Mega format 3.95" screen, tomorrow(?), I can use one of the mentioned (above) libraries?

The courier left a "missed delivery" card in my postbox today....

Fingers crossed as it has only been 3 weeks since I ordered the new screen....

Edit: As to your suggestion of sticking to a style.... It is difficult to when libraries don't support the various controllers. I HAD decided on the style of UTFT because it was easy to add methods and it has, to me, a pleasing style but it didn't and wouldn't support ILI9488 and I have 5 of those screens. The author (of UTFT) said he would NEVER support MCUFRIEND hardware because they doctored his library and wouldn't pay his royalty :(

I DID try to transplant YOUR ILI9488 coding to UTFT (as a programming exercise) but couldn't get it to work :( :( :(


Yes, there is a constraint at the moment that the JPEG x,y size needs to be an integer number of MCUs , ie typically width and height are multiples of 16.

I will see if I can fix it but it is not a priority as I have a lot of DIY and paid tasks to do at the moment.

The HX8357 libraries as published on Github do not support the ILI9488, although some hacks were described in a thread somewhere.

I totally understand. I was a contract programmer for almost 20 years, paid work ALWAYS comes first. :) :) :)

I would love to know about the hacks you mentioned, if only as a way to investigate the technique.... :)

Thank you for your libraries. :)

PS. I got a NEW format Mega TFT LCD shield and wonder if you're interested in trying to drive it? ;)


The changes to the Due library for the ILI9488 have been posted by someone here.

I have not tested these changes myself. If you want to use a Mega you might be able to transplant the code in that library.

I think David's library supports the ILI9488

The Mega variant of the HX8357 library does not support the ILI9486 driver.

Thanks for your reply. :)

Yes David HAS a library that supports ILI9488 (very well) But, AFAIK only in Uno format (28 pins) ( I could be wrong!? I quite often am). ;)

The BangGood 3.2" ILI9481 (that you support, also very well) is a Mega format shield with 36 + 2 pins (16 bit??). The new AliX Mega format shield has 36 + 14 pins (8 bit?).

I do understand you are busy though :D

Edit: David got me to uncomment 2 lines in his library and the new shield works perfectly on a Mega. Will try on a Due next....

Thanks for your interest :D

I forgot the link.

See this post.

And this post.

So modifying the Mega library should also be possible.

Sorry, bodmer… :frowning:

I replaced the setRotation method with the one from your link and my Due and new Mega 8bit shield remain white faced :frowning:

Sorry, it is the same reply I gave David for his proposed changes too.

I’m sorry… :frowning:

Could the pin mappings be different?

Thanks again :slight_smile:

The results from the serial monitor…

HX8357 Test!
Benchmark                Time (microseconds)
Screen fill              77386
Text                     27370
Lines                    264489
Horiz/Vert Lines         8365
Rectangles (outline)     6110
Rectangles (filled)      189042
Circles (filled)         148907
Circles (outline)        232754
Triangles (outline)      53075
Triangles (filled)       133337
Rounded rects (outline)  68945
Rounded rects (filled)   245498


The ILI9488 hack assumes you have selected the ILI9481 mode in the User_Setup.h file. You should get something displayed with that driver selected even on a unmodified library except I think your images will be mirrored. The rotation() code only corrects that mirroring.

The library outputs the data to draw on the display, the test results are also written to the serial port, the library has "no knowledge" that the information sent to the display did not get correctly displayed. You will get the same output even with no display plugged in.

I can't offer any more help as I do not have a display to test, and the library is not specifically written to support the ILI9488.

Thanks for all the effort and help you have so freely given.... :D

Thank you. :)