ST7793 Breakout - not working

[baliame]

Hi,

I've recently acquired a Nano 33 IoT and hooked it up to an open-smart breakout board which claims to be an ST7793.

The wiring is DB0-DB7 to D2-D9, RST to A4, CS to A3, RS to A2, WR to A1 and RD to A0. LED is hooked up to GND for continuous backlight. Lacking better options currently, these are wired from the breakout with duponts onto the breadboard that has the Nano.

Graphics test compiles using #define SUPPORT_B509_7793, but during runtime, readID() returns either 0x1414 or 0x9494, the latter seems to be more frequent. Forcing ID to be 0x7793 does nothing as nothing happens on the LCD even if I do that, so the problem seems to be two-fold where I'm both getting the wrong ID back and nothing actually works if I force the correct ID.

The LCD also didn't work with their own hacked library and examples, the ID value had even more of a variance there (saw 0x0000, 0xFFFF, and other non-specific values as well). It is the same library that is provided in the shield thread from a couple of weeks ago.

Do you have any ideas what I could do here?

[baliame]

Readreg:

12:24:54.767 -> Read Registers on MCUFRIEND UNO shield
12:24:54.767 -> controllers either read as single 16-bit
12:24:54.767 -> e.g. the ID is at readReg(0)
12:24:54.767 -> or as a sequence of 8-bit values
12:24:54.767 -> in special locations (first is dummy)
12:24:54.767 -> 
12:24:54.815 -> reg(0x0000) 77 93   ID: ILI9320, ILI9325, ILI9335, ...
12:24:54.815 -> reg(0x0004) 00 00 00 00 Manufacturer ID
12:24:54.815 -> reg(0x0009) 00 00 00 00 00  Status Register
12:24:54.863 -> reg(0x000A) 00 00   Get Power Mode
12:24:54.863 -> reg(0x000C) 00 00   Get Pixel Format
12:24:54.863 -> reg(0x0061) 00 00   RDID1 HX8347-G
12:24:54.910 -> reg(0x0062) 00 00   RDID2 HX8347-G
12:24:54.910 -> reg(0x0063) 00 00   RDID3 HX8347-G
12:24:54.910 -> reg(0x0064) 00 00   RDID1 HX8347-A
12:24:54.910 -> reg(0x0065) 00 00   RDID2 HX8347-A
12:24:54.957 -> reg(0x0066) 00 00   RDID3 HX8347-A
12:24:54.957 -> reg(0x0067) 00 00   RDID Himax HX8347-A
12:24:54.957 -> reg(0x0070) 00 00   Panel Himax HX8347-A
12:24:55.005 -> reg(0x00A1) 00 00 00 00 00  RD_DDB SSD1963
12:24:55.005 -> reg(0x00B0) 00 00   RGB Interface Signal Control
12:24:55.005 -> reg(0x00B4) 00 00   Inversion Control
12:24:55.005 -> reg(0x00B6) 00 00 00 00 00  Display Control
12:24:55.053 -> reg(0x00B7) 00 00   Entry Mode Set
12:24:55.053 -> reg(0x00BF) 00 00 00 00 00 00   ILI9481, HX8357-B
12:24:55.053 -> reg(0x00C0) 00 00 00 00 00 00 00 00 00  Panel Control
12:24:55.101 -> reg(0x00C8) 00 00 00 00 00 00 00 00 00 00 00 00 00  GAMMA
12:24:55.101 -> reg(0x00CC) 00 00   Panel Control
12:24:55.101 -> reg(0x00D0) 00 00 00    Power Control
12:24:55.101 -> reg(0x00D2) 00 00 00 00 00  NVM Read
12:24:55.148 -> reg(0x00D3) 00 00 00 00 ILI9341, ILI9488
12:24:55.148 -> reg(0x00D4) 00 00 00 00 Novatek ID
12:24:55.148 -> reg(0x00DA) 00 00   RDID1
12:24:55.196 -> reg(0x00DB) 00 00   RDID2
12:24:55.196 -> reg(0x00DC) 00 00   RDID3
12:24:55.196 -> reg(0x00E0) 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 GAMMA-P
12:24:55.243 -> reg(0x00E1) 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 GAMMA-N
12:24:55.243 -> reg(0x00EF) 00 00 00 00 00 00   ILI9327
12:24:55.243 -> reg(0x00F2) 00 00 00 00 00 00 00 00 00 00 00 00 Adjust Control 2
12:24:55.243 -> reg(0x00F6) 00 00 00 00 Interface Control

This made me realize that the data wires were wrong (readreg expects DB2-DB7 on 2-7 and then DB0-DB1 on 8-9), but that changed nothing with the graphics test.

[prenticedavid]

You can read the "similar" ST7793 issue.

I have ordered a ST7793 and am expecting it to arrive today or tomorrow. So I should be able to give a definitive answer soon.

David.

[baliame]

In the meantime I've realized I've skimmed over the critical detail that I should be using the Adafruit_TFTLCD constructor for breakouts. Unfortunately, this leads me to another problem as Adafruit_TFTLCD does not support SAMD21 boards. Is there a way I can work around this without having to use Adafruit_TFTLCD?

[prenticedavid]

The constructor arguments are all dummies for compatibility with Adafruit_TFTLCD constructor.

The Shield wiring is all configured by mcufriend_shield.h to match "official" Arduino header pinouts. I strongly advise you to just copy the appropriate SAMD21 Arduino. e.g. ZERO or M0_PRO

If you want to use some special custom wiring scheme, you write a "SPECIAL" block for mcufriend_special.h

I received my ST7793 display today. I have created a "test_7793" Branch. The rotation=2 and rotation=3 are working.

The Vertical Scroll will always have a 32 pixel stripe with garbage.

If any readers possess ILI9326, SPFD5420 or R61509V controllers please could they run diagnose_TFT_controller.ino to test the rotations. And graphictest_kbv.ino to test the "Vertical Scroll"

David.

[baliame]

I've discovered the issue with the mcufriend_shield pinout for Nano 33 IoT - it uses vastly different ports for the same pin layout.

Matching the D8, D9, D2-D7, A0-A4 layout for everything else, the ports for Nano 33 IoT would be the following:

//LCD pins   |D7  |D6  |D5  |D4  |D3  |D2  |D1  |D0  | |RD |WR |RS  |CS  |RST |
//SAMD21 pin |PA6|PA4|PA5|PA7 |PB11 |PA10|PA18 |PA6 | |PA2|PB2|PA11 |PA10 |PB8 |

I'll figure out the defines and post a pull request.

[prenticedavid]

I don't have an IOT33 but there was a recent question on Arduino.cc Forum.

I had written a SPECIAL and it is in https://github.com/prenticedavid/MCUFRIEND_kbv/blob/master/extras/unused/mcufriend_special_3.h

//####################################### NANO IOT 33 ############################
#elif defined(__SAMD21G18A__) && defined(ARDUINO_SAMD_NANO_33_IOT)     //regular UNO shield on NANO IOT 33
#warning building for NANO IOT 33 
//LCD pins   |D7  |D6  |D5  |D4  |D3  |D2  |D1  |D0  | |RD |WR |RS  |CS  |RST |
//SAMD21 pin |PA6 |PA4 |PA5 |PA7 |PB11|PB10|PA20|PA18| |PA2|PB2|PA11|PA10|PB08|

So it looks as if you have different mapping for D3, D2, D1, D0. Apparently this SPECIAL worked ok. I do not own an IOT33.

If I receive feedback about delays etc, I will put this SPECIAL into mcufriend_shield.h because there are Nano Adapters that receive Uno Shields. (I use them for Nano, Nano-EVERY, Nano-BLE33, Thinary, ...

David.

[baliame]

You're right, I actually don't know how I came up with those port numbers. Double-checked yours against the official pinout diagram and it seems correct. I'll test it out as soon as I get a breather's worth of break from Christmas.

[baliame]

Alright, so I've managed to get it working on the test_7793 branch with the linked SPECIAL, so we do have significant progress - and yes, I've noticed the issues on rotation = 0 and rotation = 1. I can round them up if you need me to - it's mostly some artifacts that I can probably attribute to the flimsy dupont setup I have going right now, as well as software scrolling being completely broken.

I've also run into a compilation error on test_7793, NL being declared within the switch-case won't compile with the gotos going around its definition (mcufriend_kbv.cpp:L475), so to get it to compile I moved it to the top of setRotation.

[prenticedavid]

I don't expect any issues with all 4 rotations. Please explain. It is best to run diagnose_TFT_controller to see the rotation accuracy, alignment, ...

NL is possibly a system define. So it is wise to change to different spelling. I only used NL because it is a field name in every controller datasheet.

David.

[baliame]

I've fixed the wiring issues, that seems to have eliminated all artifacts, so it seems even the software scroll issue was just flimsy duponts. Overall, everything seems to work great now, so I can confirm that what you have in special_3 for Nano 33 IoT is fine.

Regarding the compilation issue, it's not about a system define, here's the output from prior to fixing it:

In file included from /home/baliame/Arduino/libraries/MCUFRIEND_kbv/MCUFRIEND_kbv.cpp: In member function 'virtual void MCUFRIEND_kbv::setRotation(uint8_t)':
/home/baliame/Arduino/libraries/MCUFRIEND_kbv/MCUFRIEND_kbv.cpp:482:9: error: jump to case label [-fpermissive]
         default:
         ^~~~~~~
/home/baliame/Arduino/libraries/MCUFRIEND_kbv/MCUFRIEND_kbv.cpp:475:22: note:   crosses initialization of 'uint16_t NL'
             uint16_t NL = ((400 / 8) - 1) << 9;  // 400 rows
                      ^~
/home/baliame/Arduino/libraries/MCUFRIEND_kbv/MCUFRIEND_kbv.cpp:489:11: error: jump to label 'common_ORG' [-fpermissive]
           common_ORG:
           ^~~~~~~~~~
/home/baliame/Arduino/libraries/MCUFRIEND_kbv/MCUFRIEND_kbv.cpp:467:18: note:   from here
             goto common_ORG;
                  ^~~~~~~~~~
/home/baliame/Arduino/libraries/MCUFRIEND_kbv/MCUFRIEND_kbv.cpp:475:22: note:   crosses initialization of 'uint16_t NL'
             uint16_t NL = ((400 / 8) - 1) << 9;  // 400 rows
                      ^~
exit status 1
Error compiling for board Arduino NANO 33 IoT.

Again, simply fixed by moving the declaration of NL out of the switch section.

[prenticedavid]

Yes, you can either declare NL at the top of void MCUFRIEND_kbv::setRotation(uint8_t r) Or you could put it inside braces.

Confession. The recent code change for ST7793 has only been compiled and run on ATmega328P. I generally find the odd whinge when compiling on STM32, ESP32, ...

I would be interested in reducing the conservative delays from the IOT33 block. If you are using AS7.0, UV5 or Rowley make sure that you use sensible Optimisation. e.g. -O2 or -Os It makes a big difference to the GPIO bus writes.

David.