JT035IPS02 640x480 display config

[ZJO]

I recently purchased this https://www.aliexpress.com/item/4000075 ... 4c4d1pbk89 640x480 3.5 inch JT035IPS02-V0 LCD screen.

I didn't really do much research and have since realised these are not that common and I can't find any information about what needs to be in my config.txt to get the display working nicely.

Using the this config below the display looks perfect as it's booting but then the colours get whacked out once some more drivers have loaded and the frontend starts.

Code: Select all

# Enable DPI
dtoverlay=dpi24
overscan_left=0
overscan_right=0
overscan_top=0
overscan_bottom=0
enable_dpi_lcd=1
display_default_lcd=1
dpi_group=2
dpi_mode=7

# Enable 640x480 custom display mode
framebuffer_width=640
framebuffer_height=480
display_rotate=2
dpi_output_format=458775
hdmi_timings=640 88 44 2 42 480 32 16 2 14 0 0 0 60 0 18432000 1

I took the dpi_output_format & hdmi_timings from a DPI config.txt generator I found on the forum using the datatsheet for the LCD. I'm not convinced I've done it properly or that the datasheet is complete.

DPI config.txt generator: https://docs.google.com/spreadsheets/d/ ... sp=sharing

Datasheet: https://drive.google.com/file/d/1Anxe0w ... sp=sharing

My question is has anyone here got any idea where I've gone wrong and how can I get the display working 100%.

[floppes]

If I'm correct, dpi_mode=7 is 640x480 with 85 Hz (source). Try dpi_mode=4 for 60 Hz or even better dpi_mode=87 for custom timings through dpi_timings.

I would also remove framebuffer_width and framebuffer_height as they are usually not needed.

The DPI config generator does not take into account the settings for sync, front porch and back porch for the pixel clock. It needs to be:

Horizontal period: HSYNC + HBP + H_LEN + HFP = 2 + 42 + 640 + 44 = 728
Total period: (VSYNC + VBP + V_LEN + VFP) * horizontal period * refresh rate = (2 + 14 + 480 + 16) * 728 * 60 = 22364160

When I was working with DPI a few years ago, the pixel clock had to be a multiple of an internal clock. Therefore an odd number such as 22364160 was not working. The next working multiple is 32000000.

Your hdmi_timings for the polarity look odd and you can use dpi_timings to make it more consistent. It should be:
dpi_timings=640 0 44 2 42 480 0 16 2 14 0 0 0 60 0 32000000 1

Hope that helps

[ZJO]

Thanks for taking the time to reply – that was very helpful. Seems like it's close now but still getting whacked out colours when the frontend loads, which is weird because up until that starts everything looks fine.

Code: Select all

# Enable DPI
dtoverlay=dpi24
overscan_left=0
overscan_right=0
overscan_top=0
overscan_bottom=0
enable_dpi_lcd=1
display_default_lcd=1
dpi_group=2
dpi_mode=87

# Enable 640x480 custom display mode
#framebuffer_width=640
#framebuffer_height=480
display_rotate=2
dpi_output_format=22364160
hdmi_timings=640 0 44 2 42 480 0 16 2 14 0 0 0 60 0 32000000 1

Picture: https://drive.google.com/file/d/1J_mMy0 ... sp=sharing

[floppes]

The color channels seem to be swapped. You can play with the rgb_order setting in the DPI generator.
Currently you have dpi_output_format=22364160, which means rgb_order is 0. That's not a valid value.

How do you connect the display to the Raspberry Pi?
And how do you generate the 18 V for the backlight?

[ZJO]

I misread your first reply and thought 22364160 should be the dpi_output_format. That was very wrong

I don't think the colours are inverted in that image, they are just messed up. They look correct during startup and on the splash screen.

The correct rgb_order is definetely 1 (rgb).

How can I find the correct dpi_output_format magic number for this display?

How do you connect the display to the Raspberry Pi?
And how do you generate the 18 V for the backlight?

I should point out this screen is connected to a circuit sword build.

[floppes]

Ok, the Circuit Sword generates the correct voltage for the backlight. Your display is pin-compatible to the 320x280 pixel display that Kite supplies. Kite also offered a 640x480 "HD" display for the Circuit Sword. Is this the JT035IPS02-V0 you are using?

Anyway, you can use Kite's config.txt as a reference for your settings:

He uses dpi_output_format=516117 which means the output_format is set to RGB_666. This makes sense because RGB_888 uses almost all GPIOs and the difference isn't really noticable with retro games. You should also set dtoverlay=dpi18 to match RGB_666.

With Kite's dpi_output_format most signals are inverted in polarity (hsync_polarity, vsync_polarity etc.). There are no signal diagrams in the display's datasheet to derive these settings. If they are wrong, this could lead to shifted colors as you are experiencing.

Kite's dpi_timings kind of match your datasheet, but they seem to be interpreted wrong. I'd go with my recommendation but adjust the polarity according to dpi_output_format:
dpi_timings=640 1 44 2 42 480 1 16 2 14 0 0 0 60 0 32000000 1

In summary, try:

Code: Select all

dtoverlay=dpi18
dpi_output_format=516117
dpi_timings=640 1 44 2 42 480 1 16 2 14 0 0 0 60 0 32000000 1

If this doesn't work, try this without inverted polarities:

Code: Select all

dtoverlay=dpi18
dpi_output_format=21
dpi_timings=640 0 44 2 42 480 0 16 2 14 0 0 0 60 0 32000000 1

[ZJO]

Kite also offered a 640x480 "HD" display for the Circuit Sword. Is this the JT035IPS02-V0 you are using?

No, this is a display I found on Aliex which I assumed might work out of the box. I had been using the original config.txt as a starting point. Thanks for confirming the RGB_666 I messed with the 888 for while as the display is 24bit but realised that would be using all GPIO pins, as you already mentioned.

I've tried both of your suggestions and this one seems to be the one that's working:

Code: Select all

dtoverlay=dpi18
dpi_output_format=516117
dpi_timings=640 1 44 2 42 480 1 16 2 14 0 0 0 60 0 32000000 1

The other gave me no display and some vertical black bars. I think we can safely say the polarity needs to be inverted.

The odd thing is sometimes the screen looks fine when navigating the frontend. I get flashes of perfect colour. I ran the cs-tester.py provided by Kite and weirdly the COLOUR.png etc displays perfectly. https://github.com/kiteretro/Circuit-Sw ... /cs-tester

Also if I load each individual test PNG (BLUE.png, RED.png etc.) from that directory linked above using the command

Code: Select all

./pngview -l 99999 RGB.png

they all load with no issue. But underneath the emulationstation screen is whacked out grey and distorted text.

Pictures: https://drive.google.com/drive/folders/ ... sp=sharing

I'm starting to think the display might need some kind of driver – is that something DPI displays need? I'm not sure. I read that fbtft has a generic driver for a parallel display called flexpfb that can be used to define/alter certain pins on the display https://github.com/notro/fbtft

It's strange because the display seems to be functioning, it's just not working correctly with the frontend or when I'm in a game

Thanks for your help with this so far!

[floppes]

I think you are on the right way. But the test images are not displayed correctly:

1_.png (182.89 KiB) Viewed 11281 times

should be

1.png (9.58 KiB) Viewed 11281 times

And

2_.png (149.99 KiB) Viewed 11281 times

should be

2.png (3.95 KiB) Viewed 11281 times

There are still some problems with color gradients which you also see in EmulationStation. But so far I have no idea what is wrong. It must be the configuration, not the display itself.

Did you try Kite's settings?

Code: Select all

dpi_output_format=516117
dpi_timings=640 1 32 48 88 480 1 13 3 32 0 0 0 60 0 32000000 1

For DPI there is no driver needed. The parameters necessary for the Pi can be set through config.txt.

The panel driver chip on the display usually needs to be initialized and configured. You find chips like ILI9488 on the display which have lots of configuration options. This is done via SPI on the display pins SDO (7), SDI (11), SCL (10) and CS (9). But the datasheet on page 7 clearly states that it's not necessary for your display: "And We had preset the initialization code in LCM,so you don’t need SPI to initialize this module."

The Circuit Sword has an ATmega microcontroller which does the display initialization: LCD.ino

This initialization may fit Kite's "HD" display but not yours. You can compile your own firmware and disable the display initialization. Be sure to create a backup of the current firmware before you flash your own, in case you want to go back.

[ZJO]

I started with Kites original settings and they have a similar output to the timing/dpi output you suggested.

Interesting re: the micro controller, I assume that passes the display to the CM3? Although I have some experience with arduino, I'm not sure what's going on in Kites code. I have emailed him asking for any pointers to get the display running.

I had also contacted the email address on the data sheet asking for more information about the dpi_output_format stats.

They have provided this responce – any idea how this translates?

Screenshot 2021-10-18 at 09.39.05.png (369.81 KiB) Viewed 11270 times

[floppes]

This helps a little for the signal polarities. But the Raspberry Pi documentation doesn't really explain what it means with "polarity inverted"... is it high or low? We would need to confirm the timings with an oscilloscope. I have one here

The microcontroller controls the SPI pins of the display and writes the panel controller registers. In Kite's public code, register 0x23 for RGB interface control is not written, so it should stay at the default value 0xA2. The remaining data pins of the display are directly connected to the Pi. The microcontroller wouldn't be fast enough to fill the screen with 60 Hz

I find this display very interesting and I'm thinking about ordering one. But it would take weeks to arrive here in Germany. You don't happen to have a second display and live in Europe?

Let's see what Kite replies.