Blank screen on Kedei 3.5" version 6.3

[firstorderexperiment]

No matter what I do with this it seems that the display remains white and unchanging. I am able to output to the screen just fine with https://github.com/lzto/RaspberryPi_KeDei_35_lcd_v62 for a test to make sure the display does actually work.

Running latest Raspbian Stretch on a Pi 3 Model B+.

I've tried compiling and running with and without DMA transfers and at various SPI_BUS_CLOCK_DIVISOR settings - 10, 12, 24, 40, 100, 200, (cleaning out build/ each time), with and without SPI enabled. Verified no dtoverlay settings in boot/config.txt

Sample compilation command:

cmake -DSPI_BUS_CLOCK_DIVISOR=24 -DKEDEI_V63_MPI3501=ON -DUSE_DMA_TRANSFERS=OFF ..

Running with:

sudo ./fbcp-ili9341

Which spits out:

bcm_host_get_peripheral_address: 0x3f000000, bcm_host_get_peripheral_size: 16777216, bcm_host_get_sdram_address: 0xc0000000
BCM core speed: current: 250000000hz, max turbo: 400000000hz. SPI CDIV: 24, SPI max frequency: 16666667hz
Initializing display
Creating SPI task thread
InitSPI done
DISPLAY_FLIP_ORIENTATION_IN_SOFTWARE: Swapping width/height to update display in portrait mode to minimize tearing.
Relevant source display area size with overscan cropped away: 1080x1920.
Source GPU display is 1080x1920. Output SPI display is 320x480 with a drawable area of 320x480. Applying scaling factor horiz=0.25x & vert=0.25x, xOffset: 25, yOffset: 0, scaledWidth: 270, scaledHeight: 480
Creating dispmanX resource of size 270x480 (aspect ratio=0.562500).
GPU grab rectangle is offset x=0,y=0, size w=270xh=480, aspect ratio=0.562500
All initialized, now running main loop...

Any thoughts?

[kpishere]

Yes, so I'm seeing the same behaviour. I did notice some change however. With project https://github.com/lzto/RaspberryPi_KeDei_35_lcd_v62.git, this does work on my '6.3' display. Firstly, SPI overlay must be enabled for it t work. Then, when it executes .. you see the screen that you should see with juj's driver before it gets painted over. This suggests to me that there is an issue with the initialization on this driver right now. Thought I'd try to transpose that code's initialization to this driver but .. it looks daunting. I need more background understanding to do this.

Here is what I see .. the working initialization ...

They are pretty comparable but not exactly sure what is happening

lcd_cmd() and lcd_data() are sent separately and SPI_TRANSFER() is interlacing data and commands?

void lcd_init(void)
{
//reset display
lcd_rst();
//kedei 6.2
lcd_cmd(0x00);
delayms(10);
lcd_cmd(0xFF); lcd_cmd(0xFF);
delayms(10);
lcd_cmd(0xFF); lcd_cmd(0xFF); lcd_cmd(0xFF); lcd_cmd(0xFF);
delayms(15);
lcd_cmd(0x11);
delayms(150);

lcd_cmd(0xB0); lcd_data(0x00);
lcd_cmd(0xB3); lcd_data(0x02); lcd_data(0x00); lcd_data(0x00); lcd_data(0x00);
lcd_cmd(0xB9); lcd_data(0x01); lcd_data(0x00); lcd_data(0x0F); lcd_data(0x0F);
lcd_cmd(0xC0); lcd_data(0x13); lcd_data(0x3B); lcd_data(0x00); lcd_data(0x02);
               lcd_data(0x00); lcd_data(0x01); lcd_data(0x00); lcd_data(0x43);
lcd_cmd(0xC1); lcd_data(0x08); lcd_data(0x0F); lcd_data(0x08); lcd_data(0x08);
lcd_cmd(0xC4); lcd_data(0x11); lcd_data(0x07); lcd_data(0x03); lcd_data(0x04);
lcd_cmd(0xC6); lcd_data(0x00);
lcd_cmd(0xC8); lcd_data(0x03); lcd_data(0x03); lcd_data(0x13); lcd_data(0x5C);
               lcd_data(0x03); lcd_data(0x07); lcd_data(0x14); lcd_data(0x08);
               lcd_data(0x00); lcd_data(0x21); lcd_data(0x08); lcd_data(0x14);
               lcd_data(0x07); lcd_data(0x53); lcd_data(0x0C); lcd_data(0x13);
               lcd_data(0x03); lcd_data(0x03); lcd_data(0x21); lcd_data(0x00);
lcd_cmd(0x35); lcd_data(0x00);
lcd_cmd(0x36); lcd_data(0x60);
lcd_cmd(0x3A); lcd_data(0x55);
lcd_cmd(0x44); lcd_data(0x00); lcd_data(0x01);
lcd_cmd(0xD0); lcd_data(0x07); lcd_data(0x07); lcd_data(0x1D); lcd_data(0x03);
lcd_cmd(0xD1); lcd_data(0x03); lcd_data(0x30); lcd_data(0x10);
lcd_cmd(0xD2); lcd_data(0x03); lcd_data(0x14); lcd_data(0x04);
lcd_cmd(0x29);

delayms(30);

lcd_cmd(0x2A); lcd_data(0x00); lcd_data(0x00); lcd_data(0x01); lcd_data(0x3F);
lcd_cmd(0x2B); lcd_data(0x00); lcd_data(0x00); lcd_data(0x01); lcd_data(0xE0);
lcd_cmd(0xB4); lcd_data(0x00);

lcd_cmd(0x2C);

delayms(10);
lcd_setrotation(0);

}

The init that isn't working in juj's driver :

BEGIN_SPI_COMMUNICATION();
{
CLEAR_GPIO(GPIO_SPI0_CE0); // Enable Touch
CLEAR_GPIO(GPIO_SPI0_CE1); // Enable Display

BEGIN_SPI_COMMUNICATION();

usleep(25*1000);

SET_GPIO(GPIO_SPI0_CE0); // Disable Touch
usleep(25*1000);

SPI_TRANSFER(0x00000000); // This command seems to be Reset
usleep(120*1000);

SPI_TRANSFER(0x00ffffff);
usleep(50*1000);
SPI_TRANSFER(0xffffff11);
usleep(60*1000);

SPI_TRANSFER(0xB9001100, 0x00, 0xFF, 0x00, 0x83, 0x00, 0x57);
usleep(5*1000);

SPI_TRANSFER(0xB6001100, 0x00, 0x2C);
SPI_TRANSFER(0x11001100/*Sleep Out*/);
usleep(150*1000);

SPI_TRANSFER(0x3A001100/*Interface Pixel Format*/, 0x00, 0x55);
SPI_TRANSFER(0xB0001100, 0x00, 0x68);
SPI_TRANSFER(0xCC001100, 0x00, 0x09);
SPI_TRANSFER(0xB3001100, 0x00, 0x43, 0x00, 0x00, 0x00, 0x06, 0x00, 0x06);
SPI_TRANSFER(0xB1001100, 0x00, 0x00, 0x00, 0x15, 0x00, 0x1C, 0x00, 0x1C, 0x00, 0x83, 0x00, 0x44);
SPI_TRANSFER(0xC0001100, 0x00, 0x24, 0x00, 0x24, 0x00, 0x01, 0x00, 0x3C, 0x00, 0x1E, 0x00, 0x08);
SPI_TRANSFER(0xB4001100, 0x00, 0x02, 0x00, 0x40, 0x00, 0x00, 0x00, 0x2A, 0x00, 0x2A, 0x00, 0x0D, 0x00, 0x4F);
SPI_TRANSFER(0xE0001100, 0x00, 0x02, 0x00, 0x08, 0x00, 0x11, 0x00, 0x23, 0x00, 0x2C, 0x00, 0x40, 0x00, 0x4A, 0x00, 0x52, 0x00, 0x48, 0x00, 0x41, 0x00, 0x3C, 0x00, 0x33, 0x00, 0x2E, 0x00, 0x28, 0x00, 0x27, 0x00, 0x1B, 0x00, 0x02, 0x00, 0x08, 0x00, 0x11, 0x00, 0x23, 0x00, 0x2C, 0x00, 0x40, 0x00, 0x4A, 0x00, 0x52, 0x00, 0x48, 0x00, 0x41, 0x00, 0x3C, 0x00, 0x33, 0x00, 0x2E, 0x00, 0x28, 0x00, 0x27, 0x00, 0x1B, 0x00, 0x00, 0x00, 0x01);

#define MADCTL_BGR_PIXEL_ORDER (1<<3)
#define MADCTL_ROW_COLUMN_EXCHANGE (1<<5)
#define MADCTL_COLUMN_ADDRESS_ORDER_SWAP (1<<6)
#define MADCTL_ROW_ADDRESS_ORDER_SWAP (1<<7)

[kpishere]

Yes, I had started to change the init part a bit already .. with this..

diff --git a/mpi3501.cpp b/mpi3501.cpp
index 67178a1..bb51fe4 100644
--- a/mpi3501.cpp
+++ b/mpi3501.cpp
@@ -56,9 +56,9 @@ void InitKeDeiV63()
SPI_TRANSFER(0x00000000); // This command seems to be Reset
usleep(120*1000);

• SPI_TRANSFER(0x00000100);

• SPI_TRANSFER(0x00ffffff);^M
  usleep(50*1000);

• SPI_TRANSFER(0x00001100);

• SPI_TRANSFER(0xffffff11);^M
  usleep(60*1000);

  SPI_TRANSFER(0xB9001100, 0x00, 0xFF, 0x00, 0x83, 0x00, 0x57);

[usagi87]

Hey, I'm having problem when run it start normally then craches giving a segmentation fault error?

got picture now using neuromancer85 fork, but colors look weird and refersh rate a bit slow.

[zerog2k]

thanks @kpishere, your fork works for me with
-DSPI_BUS_CLOCK_DIVISOR=16 -DKEDEI_V63_MPI3501=ON -DUSE_DMA_TRANSFERS=OFF
hoping that your PR #76 can make it back into this, and along with #90 to make it possible to have separate framebuffer this would be awsome!
(I too am so disappointed that kedei only provides entire black-box kernel/images, which is super scary. I just want a slow framebuffer I can make it a simple status display and control panel.)

[kpishere]

@zerog2k No worries. Glad it works. I'm just getting back into this after a summer break, hope to have pen calibration utility in there too.

[zerog2k]

hi @kpishere any updates on this? do you need any help testing?

[kpishere]

@zerog2k It is essentially complete. The device does not support screen blanking but pen calibration works well. Screen works well too. Slower than the others, but OK for largely static gui displays. no good for gaming. Don't know when/if @juj will ever merge the pull request. .. oh, you can't get it in my fork kpishere/fbcp-ili9341

[zerog2k]

Thanks! I'm happy with low fps - just trying to use for alarm panel/status display for Home Assistant!

[juj]

Closing out old issues, not sure if there is an issue with KeDei still, feel free to reopen if you are still actively struggling on it.