id 0x9797 is not supported - please add

[MarcoKu]

Read Registers on MCUFRIEND UNO shield controllers either read as single 16-bit e.g. the ID is at readReg(0) or as a sequence of 8-bit values in special locations (first is dummy)

reg(0x0000) 97 97 ID: ILI9320, ILI9325, ILI9335, ... reg(0x0004) 97 97 97 97 Manufacturer ID reg(0x0009) 97 97 97 97 97 Status Register reg(0x000A) 97 97 Get Power Mode reg(0x000C) 97 97 Get Pixel Format reg(0x0061) 97 97 RDID1 HX8347-G reg(0x0062) 97 97 RDID2 HX8347-G reg(0x0063) 97 97 RDID3 HX8347-G reg(0x0064) 97 97 RDID1 HX8347-A reg(0x0065) 97 97 RDID2 HX8347-A reg(0x0066) 97 97 RDID3 HX8347-A reg(0x0067) 97 97 RDID Himax HX8347-A reg(0x0070) 97 97 Panel Himax HX8347-A reg(0x00A1) 97 97 97 97 97 RD_DDB SSD1963 reg(0x00B0) 97 97 RGB Interface Signal Control reg(0x00B4) 97 97 Inversion Control reg(0x00B6) 97 97 97 97 97 Display Control reg(0x00B7) 97 97 Entry Mode Set reg(0x00BF) 97 97 97 97 97 97 ILI9481, HX8357-B reg(0x00C0) 97 97 97 97 97 97 97 97 97 Panel Control reg(0x00C8) 97 97 97 97 97 97 97 97 97 97 97 97 97 GAMMA reg(0x00CC) 97 97 Panel Control reg(0x00D0) 97 97 97 Power Control reg(0x00D2) 97 97 97 97 97 NVM Read reg(0x00D3) 97 97 97 97 ILI9341, ILI9488 reg(0x00D4) 97 97 97 97 Novatek ID reg(0x00DA) 97 97 RDID1 reg(0x00DB) 97 97 RDID2 reg(0x00DC) 97 97 RDID3 reg(0x00E0) 97 97 97 97 97 97 97 97 97 97 97 97 97 97 97 97 GAMMA-P reg(0x00E1) 97 97 97 97 97 97 97 97 97 97 97 97 97 97 97 97 GAMMA-N reg(0x00EF) 97 97 97 97 97 97 ILI9327 reg(0x00F2) 97 97 97 97 97 97 97 97 97 97 97 97 Adjust Control 2 reg(0x00F6) 97 97 97 97 Interface Control

Thank you!

[prenticedavid]

Please read this thread on Arduino.cc forum https://forum.arduino.cc/index.php?topic=567506.msg3867389#msg3867389

I have requested a datasheet from Solomon Systech with no response. I do not think that they reply to requests. If you can find a datasheet for the SSD1297 I can support it.

Meanwhile, you can enableSUPPORT_1289 and force the ID withtft.begin(0x1289)

I would appreciate a report back from you about graphictest_kbv. Ideally a video. Otherwise unusual photos or written description is fine.

David.

Edit. I have found a datasheet for SSD1297 (rev 0.11). The datasheet claims to return 0x9999 for ID. I still suspect that your 0x9797 display might be SSD1297.

[prenticedavid]

Bump.

Please read https://forum.arduino.cc/index.php?topic=567506.msg3876283#msg3876283

David.

[MarcoKu]

Hello, I made the changings: enableSUPPORT_1289 and force the ID withtft.begin(0x1289). Now I also have the issue, that the color green is missing. Only red and blue and the combinations of them are working.

[prenticedavid]

You have restored my sanity. So it is very likely to be SSD1297. Please run the sketch that I posted in http://forum.arduino.cc/index.php?topic=567506.msg3877011#msg3877011

And let me know what you see. A photo would be nice.

I am hoping that the undocumented registers 0x23 and 0x24 do something on your controller. But it would be useful to just see what colour grades are available.

David.

[MarcoKu]

Hi prenticedavid,

I installed the sketch. See result on the photo.

Best regards Marco

Am Di., 18. Sep. 2018 um 17:56 Uhr schrieb prenticedavid < notifications@github.com>:

You have restored my sanity. So it is very likely to be SSD1297. Please run the sketch that I posted in http://forum.arduino.cc/index.php?topic=567506.msg3877011#msg3877011

And let me know what you see. A photo would be nice.

I am hoping that the undocumented registers 0x23 and 0x24 do something on your controller. But it would be useful to just see what colour grades are available.

David.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/prenticedavid/MCUFRIEND_kbv/issues/64#issuecomment-422448557, or mute the thread https://github.com/notifications/unsubscribe-auth/ALYHxOJsu2khSiucMPjkzt49YvOaWRy_ks5ucRevgaJpZM4WoFc9 .

[prenticedavid]

What photo? I do not see any photo or attachment.

[MarcoKu]

That is strange, i see the attachment in the email in my sent folder. I try again: Vorschau für Anhang "20180919_164538.jpg" ansehen 20180919_164538.jpg 426 KB https://mail.google.com/mail/u/0?ui=2&ik=7fde997287&attid=0.1&permmsgid=msg-a:r-2346230120957537131&th=165f2585c96e8331&view=att&disp=safe&realattid=f_jm99x67v0

Am Mi., 19. Sep. 2018 um 17:27 Uhr schrieb prenticedavid < notifications@github.com>:

What photo? I do not see an photo or attachment.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/prenticedavid/MCUFRIEND_kbv/issues/64#issuecomment-422846935, or mute the thread https://github.com/notifications/unsubscribe-auth/ALYHxKP8-vXrRhHkGyIMkY3gXLprQpdPks5ucmJ3gaJpZM4WoFc9 .

[prenticedavid]

If I click on your link, I have to sign up for GMail. I have no idea whatever GMail is. I certainly do not want to sign up to it. I have quite happily viewed files and images on Google. I have never been forced to sign up to GMail.

Surely you can attach your image directly to your GitHub message. Or to a Forum message on Arduino.cc Displays forum.

David.

[MarcoKu]

Here is the photo:

[prenticedavid]

Your screen has been in the wars !! How long have you had this screen?

On a SSD1289 you get different pictures for mask value 0000FC, FC0000 and FC00FC. All Red, Green, Blue colours are present with a smooth gradation. Different mask values affect different colours.

Your controller does not seem to show any Green at all. The Blue does not seem to grade. The Red grades but seems to grade different areas for 000400 and 00FC00

The SSD1297 does not have reg(0x23) or reg(0x24). Or at least they are not documented. The SSD1289 registers that could affect the Green are not present (or documented) for SSD1297. The SSD1297 seems to have similar power-on-reset default value to the SSD1289. There are trivial bit differences in a couple of registers. More in naming than functionality.

I will have to think about your missing Green. I was hoping that it would just be a documentation "feature".

I will post something later on Arduino.cc I am sure that we can get this "usable". Another owner has "missing Green". So it is unlikely to be a fault with your screen.

David.

[MarcoKu]

Hi David,

thank you for investing all the time into it. On the photo the Blue does not seem to grade. But in reality it grades. The grading depends on the viewing angle (sorry, my english is not that good).

Marco

[prenticedavid]

No problem. I had assumed that Blue and Red graded smoothly. Camera angle makes a big difference.

[prenticedavid]

I can't see any register that would make any difference to the Green output. The library tft.begin(0x1289) sets some unusual values for reg(0x0B) and reg(0x11). It is worth restoring the Power-On-Reset values in setup() e.g.

    if (tft.width() == 0) {
        Serial.println("SSD1289 support is NOT enabled");
        Serial.println("#define SUPPORT_1289 in MCUFRIEND_kbv.cpp");
    }
//    tft.WriteCmdData(0x11, 0x6070);  //init DFM=3, TY=1, ID=3
    tft.WriteCmdData(0x11, 0x6830);  //POR DFM=3, OEDef=1, TY=0, ID=3
    tft.WriteCmdData(0x0B, 0x5308);  //POR NO=1, SDT=1, EQ=3, RTN=8
//    for (int i = 0x30; i <= 0x3B; i++) tft.WriteCmdData(i, 0);
}

I can't think of anything else to try.

If all else fails, you can just use the TFT with Blue and Red. Which is not satisfactory. I would ask for a refund from Ebay / AliExpress.

David.

[KlausNZ]

Hi David, I do have the same display and your sketch is the first one I got something on the screen. Thanks heaps for that! Despite Marco's missing green I guess I got his one in my display ;)

Any ideas?

[prenticedavid]

This is interesting. You appear to have a fixed Green. Marco has no Green at all.

This implies that it is NOT a software problem but a hardware problem with the Panel manufacture.

I have always assumed that these Ebay displays are constructed with surplus panels from the mobile phone market. Panels might be Quality Control failures or simply no longer required as screen replacements on obsolete phones.

1. when did you buy this display?

2. have you told the shop that it does not work?

3. have you tried adding the WriteCmdData() statements for regs 0x0B, 0x11 in setup() ?

4. have you tried setting the Gamma registers to 0 i.e. regs 0x30 .. 0x3B ?

5. please confirm that you get the same picture for FC0000, 00FC00, 0000FC, FC00FC. This means that reg(0x23) is not present i.e. as documented in the SSD1297 datasheet.

David.

[MarcoKu]

If I put my shield onto the UNO while the UNO is powered, sometimes i get a green color (I think it depends on the order, the pins are connected while putting the shield onto the UNO - the pin side with the analog pins). But in this case, no red color is available (red becomes yellow). Also no black (because green is always active)! When i reset the UNO green is still active all the time. If I power off the UNO and power on again, green is not available anymore.

[prenticedavid]

It is never wise to plug a shield when powered.

Check the 3.3V pin with a DMM. Swap the Arduino with a different one. If you have a 3.3V Due there are no worries about bad Uno 3.3V regulator.

Does your display have an AMS1117 regulator for the backlight? Does it have 74HC245 or 74VHC245 buffer chips?

Check that the back of the screen is not shorting with the pcb underneath. Most are mounted with double sided sticky 2mm foam pads. Some just have double sided Sellotape which is too thin. Slip some paper in the gap.

Please say whether you tried the WriteCmdData() statements.

David.

[KlausNZ]

Hi David,

I disconnected my Uno and reconnected it having the green disappear as with Marco.

@MarcoKu The text in your screenshot has only a sliver of purple where mine is really purple. Is this purple with you as well and only an effect of angle and camera?

I tried the WriteCmdData() statements with no change in behaviour. And the same here as well - If I attach the shield while the Uno is powered on, I have a full green. Seems like a static load somehow which would indicate a fault in production?

I can't see any regulator for the backlight and the two buffer chips are SUM74HC245T.

The display (incl. Uno) is from ALiExpress and I got it about a fortnight ago. Just started testing. I also ordered yesterday another display from another dealer to see if it's any different.

Cheers, Klaus

[MarcoKu]

Hi Klaus,

yes, also my text is really purple. As you assumed it is only an effect of angle and camera I bought mine at eBay (2 weeks ago). I also have a 3.5inch TFT from mcufriend which works perfect!

regards Marco

[prenticedavid]

@Marco,

The controller is similar to SSD1289 but has reduced register set e.g. SSD1297.

All Mcufriend shields use the 3.3V pin to operate the level shifter buffers 74HC245 Older shields contained an AMS1117 regulator on the pcb. It supplied 3.3V to the backlight. Newer shields omit the AMS1117. They must contain an extra series resistor for the backlight from 5V.

I received a Uno clone with "missing" 3.3V chip. Very few Uno owners (and shields) ever use the 3.3V pin. However the Mcufriend Displays do use it. If your 3.5 Display works, your Arduino is probably fine.

I presume that you have checked the sticky tape that mounts the TFT module to the pcb. Slide some paper in the gap. Do not try unsticking it. Some tape is very strong.

Both of you have recent purchases. I suggest that you both ask for a REFUND from Ebay / AliExpress.

David.

[prenticedavid]

I have added a "test_1297" Branch. Please try both tft.begin(0x1297) and tft.begin(0x1289) They are slightly different.

I have added an alternate init. Just comment / uncomment the 1297 / 1298 init_table16() statement.

David.

[MarcoKu]

Hi David,

I installed the Branch and tested with 0x1297 and 0x1289 once wiht 1297 init_table16() statement and once with 1298 init_table16() statement. Same as before. BUT I recognized, that with tft.invertDisplay(true); the display is showing the gray color grades in green color. On the left side is white and getting greener to the right side.

[prenticedavid]

It looks as if your Panel is showing Green and Cyan. Not very surprising because Cyan is inverse of Red. The Gray Band consists of equal shades of Red, Green, Blue. If Green is missing, you see shades of Magenta. The inverse of Magenta is Green. At least the TFT Panel is in working order.

Although the init sequences vary, the setRotation() method writes directly to reg(0x01) and reg(0x11). This is how I handle REV, TB, RL, BGR and AM. I could probably handle the GRAM directions with ID and AM in reg(0x11) and not mess with TB and RL in reg(0x01)

It would be worth trying BGR=0. You will get Red and Blue round the wrong way. But early chips often had "features". It might be that BGR is one of them.

Just add the INVERT_RGB to the 1297 settings in MCUFRIEND_kbv.cpp e.g.

    case 0x1297:
        _lcd_capable = 0 | XSA_XEA_16BIT | REV_SCREEN | INVERT_RGB;

David.

[MarcoKu]

Hi David,

I added the line "_lcd_capable = 0 | XSA_XEA_16BIT | REV_SCREEN | INVERT_RGB;" As you assumed red an blue are the wrong way, but still no Green.

Marco

[prenticedavid]

It was a long shot. And it did not work. Quite honestly, I would expect that 1297 would be a later model than 1289. Hardware bug are more likely to be in the earlier chip.

I presume that you do not live in the UK. Otherwise it would be worth £0.70 to mail the shield to me.

There are not many registers on the 1297. It has less than the 1289. I suspect that there is an undocumented (or misbehaving) bit in reg(0x01), 0x02, 0x11, 0x15.

The 1289 or 1297 does not read its internal registers. So you need guesswork rather than detective work. I can often diagnose undocumented bits in MIPI controllers by observing their write-read behaviour.

You do realise that most of these Ebay displays use obsolete controllers. Which is probably why Solomon make no effort to reply to datasheet requests. And Brokers might have access to 1000s of chips but they are not interested in a software request (unless I buy 750 chips)

David.

[KlausNZ]

Hi guys, Sorry for not participating and helping right now. Occupied with usual work and building a house. Would send you the shield, David, but living in NZ it would take a lot of time until it's there. Waiting for another shield from AliExpress with hopefully better luck. Different dealer and picture (at least that) looked different. Klaus

[prenticedavid]

It is only worth mailing cheap displays in your own country. Definitely not from NZ.

As I said earlier. Ask for your money back.

There seem to be a few screens on the Ebay market at the moment. I will wait for a UK victim.

David.

[KlausNZ]

Hi David, I did and asked for my money back. Dispute is going at AliExpress. Well, the accompanied Uno is running fine. So only partial refund. So, I got my refund!

[MarcoKu]

Hi David, I asked for replacement part. I hope, I get one with different ID. I am from Germany, so also no option to send the item to you. If I get the same item as replacement, I could send one of them to you.

Marco

[prenticedavid]

No problem. I will wait for a UK owner.

Perhaps Ebay and AliExpress vendors will make sure that their items work before selling them. Ebay refund immediately. They do not send replacements. I don't know what Ali is like.

David.

[MarcoKu]

I bought mine at eBay direct from China (4,44 Euro). They asked me, what I want (replacement or refund)

[dmsc]

Hi! I have the same display, US$3.77 with shipping, but mine was worse, did not work until I pressed the display to the PCB, I got a full refund.

About the driver, sometimes I don't have green, sometimes the display is all green, see:

[prenticedavid]

I do not find your message on GitHub.   Did you delete it immediately? A reader has sent me an 0x9797.   I have been busy with other things.     I will have another look at it but I suspect this is a whole batch of faulty screens.   

The selling price is very cheap.   The shop would have got them even cheaper from their supplier.    The shop knows that most customers do not complain. David. On Monday, 22 October 2018, 04:03:23 GMT+1, dmsc notifications@github.com wrote:

Hi! I have the same display, US$3.77 with shipping, but mine was worse, did not work until I pressed the display to the PCB, I got a full refund.

About the driver, sometimes I don't have green, sometimes the display is all green, see:

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub, or mute the thread.

[dmsc]

I do not find your message on GitHub. Did you delete it immediately?

I do see the message at https://github.com/prenticedavid/MCUFRIEND_kbv/issues/64#issuecomment-431730026 , don't know what happened.

I will have another look at it but I suspect this is a whole batch of faulty screens.    The selling price is very cheap.   The shop would have got them even cheaper from their supplier.  

Yes, I think that all that screens are rejects from some factory. Solder job in mine is really awful :stuck_out_tongue:

Anyway, thanks for your work!

[fronders]

@prenticedavid I got into the same issues as the guys above. I had both kinds of LCD chips: the ones with "no green" and the ones "all green".

THE SOLUTION:

The problem seems to be that the chip doesn't work properly in 16bit mode (65k colors). However, if you change it to 18bit mode (262k colors) the issue disappears and all the colors appear okay.

use ID 0x1289

set 18bit mode - register 0x11 instead of 0x6070 to be 0x48B0:

begin()

line 989 was:

0x0011, 0x6070,

changed to:

0x0011, 0x48B0,

setRotation()

line 471 was:

WriteCmdData(0x11, ORG | 0x6070);   // set GRAM write direction.

changed to:

WriteCmdData(0x11, ORG | 0x48B0);   // set GRAM write direction.

Modify all raw GRAM writes to now be 3 bytes per pixel: instead of RRRRRGGGGGGBBBBB to be RRRRRRxxGGGGGGxxBBBBBBxx.

drawPixel()

line 505 was:

WriteCmdData(_MW, color);

changed to:

CS_ACTIVE; 
WriteCmd(_MW); 
write8(color565_to_r(color)); 
write8(color565_to_g(color)); 
write8(color565_to_b(color)); 
CS_IDLE;

fillRect()

lines 608-609 were:

write8(hi);
write8(lo);         

changed to:

write8(color565_to_r(color)); 
write8(color565_to_g(color)); 
write8(color565_to_b(color));   

pushColors_any()

line 640 was:

write16(color);

changed to:

write8(color565_to_r(color)); 
write8(color565_to_g(color)); 
write8(color565_to_b(color));   

for this to work I added the helper functions:

static uint8_t color565_to_r(uint16_t color) {
    return ((color & 0xF800) >> 8);  // transform to rrrrrrxx
}
static uint8_t color565_to_g(uint16_t color) {
    return ((color & 0x7E0) >> 3);  // transform to ggggggxx
}
static uint8_t color565_to_b(uint16_t color) {
    return ((color & 0x1F) << 3);  // transform to bbbbbbxx
}

Attaching the resulting file with changes: MCUFRIEND_kbv.zip

[prenticedavid]

I love you.

I will try your changes when I have taken my dog out for a walk.

I first think of 18-bit, 9-bit, .. other weird modes in MIPI controllers. It had never crossed my mind for "9320" type controllers that have 16-bit command and 16-bit data.

I will have to study the SSD1297 datasheet and SSD1289 datasheet. SSD1289 has PS#=1000 for 8080-8 and PS#=0100 for 8080-9 interface SSD1297 has PS#=0011 for 8080-8 interface. No mention of 8080-9 at all!

I have written libraries for SPI controllers that require 24-bit write. It has a serious effect on performance when you need 3 SPI for every pixel. But mostly because it makes SPI DMA difficult.

David.

[fronders]

^_^

I think it is still 8080-8 (since we still have 8 data lines + WR/RS/CD etc) but in 18-bit color mode instead of 16-bit.

P. S. Can you please share the datasheets for both chips that you found (you obviously spent more time searching for latest version)

[prenticedavid]

In ENTRY register (0x11) you have DFM=2, DEN=1, TY=2 I was using DFM=3, DEN=0, TY=0.

The SSD1298 has more hardware interface modes. SSD1289 has PS#=1000 for 8080-8 and PS#=0100 for 8080-9 interface SSD1297 has PS#=0011 for 8080-8 interface. No mention of 8080-9 at all! SSD1298 has PS#=0011 for 8080-8 interface and PS#=1011 for 8080-9 interface (Table13-1)

15.3Mapping for Writing Pixel Data

from the SSD1297 datasheet shows parallel 8-bit 262K color as three 8-bit writes. The SSD1289 and SSD1298 write differently.

Anyway, a cup of tea is required. And tea to eat. Then I will try out the different write modes.

Thanks for your insight. This has been driving me crazy.

David.

[prenticedavid]

I am feeling very guilty. I had datasheets for SSD1289, SSD1297, SSD1298 and not noticed the difference between SSD1297 and SSD1298. The datasheets may have typos for the ID value but the "Writing Pixel Data" information is accurate. I just had not noticed the subtleties !!

I have put a "test_9797" Branch on GitHub. It works ok in Portrait and Landscape_Rev but drawPixel() is wrong in Landscape and Portrait_Rev. readGRAM() is not working yet.

I will have a look tomorrow.

David.

[prenticedavid]

SSD1289 datasheet: https://www.crystalfontz.com/controllers/SolomonSystech/SSD1289/335/ SSD1298 datasheet: https://www.crystalfontz.com/controllers/SolomonSystech/SSD1298/336/ SSD1297.pdf

I have discovered that both SSD1289 and SSD1297 can read GRAM and auto-increment the address. This works fine for the SSD1289 that can write and read pixels in 5-6-5 format in two 8 bit bytes. No good for SSD1297 which is written 8-8-8

MIPI controllers can configure write format and some can configure read format too. I can't see how to alter anything with the SSD1297. I also get some strange anomalies when reading GRAM (continuous or single pixel)

I suspect that reading GRAM is never going to work in MCUFRIEND_kbv. But at least you have shown how to get full RGB graphics.

I still have not fixed the drawPixel() problem in Landscape and Portrait_Rev. It seems to be related to the CAD bit which is only documented in SSD1289.

David.

[prenticedavid]

I have updated the "test_9797" branch.

I have fixed the CAD problem. I have configured for read 6-6-6 now. Unfortunately readGRAM() and pushColors() go haywire in "Software Scroll"

Please disable "Software Scroll" in your graphictest_kbv sketch. Then run readpixel_kbv sketch. You will see occasional blank rectangles and occasional bad pixel reads. I suspect that there is a a register bit that can synchronise GRAM read to the LCD scan.

David.

[prenticedavid]

I have merged the "test_9797" Branch into the regular "master". I will delete "test_9797" after a week.

Note that SUPPORT_1289 is undefined as default in "master". You must edit the SUPPORT_1289 line in MCUFRIEND_kbv.cpp to enable SSD1289 and SSD1297.

Enabling "SUPPORT_1289" when you do not intend to use 0x9797 or 0x1289 costs Flash memory in a Uno. This specific SUPPORT_xxx slows down the performance of OTHER controllers.
The Mega2560 is so SLOW with Uno Shields that you will not notice.

David.

[kb4jhu]

I just got the same display today from Ebay. I used the test "test_9797" and my display is working.
Thanks.

[souravg009]

Thank you guys for all the debug. My display is also working.

[mintu92]

Thanks, friends, I got the same problem, and support from this page really help me to solve my problem.

[prenticedavid]

You can install the regular v2.9.9-Release i.e. via the IDE Library Manager.

Then uncomment the SUPPORT_1289 define in MCUFRIEND_kbv.cpp

David.