Display blank after pressing or turning the rotary encoder

[SensorsIot]

Great project! Most works, but I have an issue:

When I press the rotary encoder the display shows mute. If I press a second time it goes completely white. The rotary encoder still reacts for mute and volume change, but if I double click and try to change the station it shows "preset is 4" but does not change the station. Sometimes the display returns but in a bad quality and disappears after the next click. I tried:

• The blue 128x160 1.8" display
• The red 128x160 1.8" display
• The TFT library in your link
• The new TFT library which seems to be the successor
• your bin file All have similar behavior.

I use: A normal WROOM-32 module the blue square VS1053 board

Everything works fine if I issue the commands through the web interface

[Edzelf]

Hello Andreas. I cannot reproduce this behaviour. I'm using the same hardware. After the second single-click the word "Mute" should disappear from the screen and the volume bar should be restored. The screen should never go white. Did you patch the TFT library as described in the documentation? Do the debug messages about de encoder reflect the right encoder movements?

[SensorsIot]

Thank you for your fast reply. These are lines 1095 till 1099 in TFT_ILI9163C.h case 3: _Mactrl_Data = 0b10101000; _height = _TFTWIDTH; _width = _TFTHEIGHT;//-__OFFSET; break; } and in TFT_ILI9163C_settings.h I commented all three defines because the last option was 128x160

//DID YOU HAVE A RED PCB, BLACk PCB or WHAT DISPLAY TYPE???????????? // ---> SELECT HERE <---- //#define 144_RED_PCB//128x128 //#define 144_BLACK_PCB//128x128 //#define 22_RED_PCB//240x320 //---------------------------------------

It happens now also after a while during normal operation. And The tight part of the volume bar is flickering. I use now the master branch of this library: https://github.com/sumotoy/TFT_ILI9163C

The debug messages reflect (more or less) the movements. But if teh display is white, they also sometimes "freeze". The ESP does not crash.

I am preparing a video for Sunday about this project and would be glad if it works ;-)

[Edzelf]

Hmm, the software seems correct. I had this kind of errors when the power supply was insufficient. It usually caused a reset. For all ESP32 projects: be sure to use a strong powersupply. The ESP32-radio next to me is playing day-in day-out without interruptions. I like the idea of seeing my project in one of your video's.

[SensorsIot]

Thanks for the hint. I will change the power supply

[SensorsIot]

I tried now many different things, all with more or less the same effect: Changed power to the bench supply (incl. a big capacitor across the ESP 5V) Changed displays (same make and, different make) ESP32 boards (3 different boards) 3.3v and 5 volt supply for the display This is one of the TFTs: https://www.aliexpress.com/item/Smart-Electronics-1-8-Inch-128-160-Serial-SPI-TFT-LCD-Module-Display-PCB-Adapter-Power/32607559110.html and this is the other one: https://www.banggood.com/1_8-Inch-128x160-SPI-Serial-TFT-LCD-Display-Module-p-969263.html I fear that the driver does not match my boards. What do you think?

In the meantime, I tried the examples of the library. They work ok.

[Edzelf]

If all other functions (apart from the display) work, it must have something to do with the display driver or the wiring to the display is interfering with the wiring of the rotary encoder. I use the same blue TFT board ("inteform" is written on the back side) with SD card. You may try to lower the SPI speed of the TFT by editing the line: tft->setBitrate ( 16000000 ) ; // High speed Half the speed should be good enough, I just tested it.

[SensorsIot]

It still does not work. The volume bar at the bottom is not red and green as it should. The green part is flickering (on both displays). I disconnected now the Rotary encoder completely, but this flickering is still there. I also removed the three "attachinterrupts" so the rotary encoder is completely switched off. The flickering is still there. If I change the station with the web-interface the flickering is away and the bar is green for a fraction of a second. Afterward, the flickering is back. The voltage at the LCD is 3.3 volt (checked)

[Edzelf]

The TFT normallly needs 5 Volt, as it has its own regulator on board. Or do you mean that 3.3 Volt is meassured after the regulator. There's also a "J1" that may be used to overrule the regulator.

[SensorsIot]

I think I found the issue: If the len in void displayinfo ( uint16_t inx ) is 1 (nothing to display), the display freezes white. I entered if (len > 1) { before utf8ascii ( buf ) ; and it does not freeze anymore (at least not at this place).

I still have some issues like:

• It does not connect every time to my WiFi network and goes to AP. Only after reset it connects
• The response to the rotary encoder or to IR is too slow and gets sometimes forgotten. Maybe it would be good to do also the counting in the interrupt routine and just use the resulting volume in the foreground
• The green part of the volume is somehow overwritten. It appears shortly and then flickers somehow. The red part is ok. I experimented a bit but was not successful.

Anyway, you should see it on Sunday morning. Thank you for your help!

[Edzelf]

I have changed the code. I still do not understand why an empty string sent to displayinfo can lead to this problem in your setup (and not in mine). The software should handle empty strings correctly, I can not find a problem in the code. But an extra test on empty strings does not harm.

I'm sorry I can not reproduce the (other) issues here.

I look forward to your video on Sunday.

Greetings from Holland, Ed.

[SensorsIot]

Maybe it is an issue with different versions of the Arduino environment. I installed the newest version a few days ago...

[Edzelf]

I don't think so. You said you tried it with my binary file, so it should be independant of the Arduino stuff. Can you send me the complete debug output?

[Edzelf]

Andreas. I enjoyed your video! If you can send me your project, I will fix it and send it back.

[koskee]

I am curious, where can I find said video?

[vankxr]

https://www.youtube.com/watch?v=hz65vfvbXMs&t=22s

[Edzelf]

Found a bug in the rotary switch function. It is corrected now. Hope this will cure the problem.

[gitpeut]

I am afraid it's not. But first: thanks Edzelf for the nice project. I really enjoy it.

I am using the code from May 31, 2018. No rotary encoder, just a Ali ST7735 display and a VS1053 module.

I found a (stupid) workaround for the flickering rectangles. After displaying a rectangle I write a 1x1 rectangle in the lower right corner to "catch" the flicker.

In bluetft.h I made little function to do so, and I commented out the #define dsp_fillRect line.

void dsp_fillRect( int16_t x, int16_t y, int16_t w, int16_t h, uint16_t color ){

  dbgprint ( "fillRect %3d %3d %3d %3d %04X", x,  y,  w,  h, color  );

  tft->fillRect ( x,  y,  w,  h, color ) ;

  tft->fillRect ( dsp_getwidth()-1, dsp_getheight() - 1, dsp_getwidth(), 1, BLACK ) ;                    // Paint black dot

}

But I still get an occasional invert screen or a completely blank screen. Also there is a flicker, similar to the flicker of the volume bar, after the last number of the time. I tried to find a stupid workaround for this as well, but I failed.

I have used the same display on the esp8266 radio, and there I have none of these issues. Also the ST7735 library examples work like a charm.

This flicker is only showing if a station is playing.

So maybe the display picks up data intended for the VS1053, either in software (SPI bus issue?? CS not unselected? ) or hardware ( interference?). I could not find any obvious issue in the code.

Anyone any ideas?

[Edzelf]

If I could reproduce the problem, I would first check the chip select line for the display....

[Edzelf]

Why not: tft->fillRect ( dsp_getwidth()-1, dsp_getheight() - 1, 1, 1, BLACK ) ; As the last line?

[gitpeut]

No reason.

[gitpeut]

I have to check.

[gitpeut]

:-) That was obviously a bug. Thanks, Edzelf. I tried tft->fillRect ( dsp_getwidth()-1, dsp_getheight() - 1, 1, 1, BLACK ) ; and tft->fillRect ( 0, dsp_getheight() - 1, 1, 1, RED ) ;. Both work fine. Now see if this cures my white screen and reverse displays. The flicker just after the time still is there, but that is just a nuisance. This weekend I will try tests cs with a logic analyzer.

[Edzelf]

Testing with a logic analyzer would be great. I expect some noise on the chip select. The software uses semaphores to prevent simultaniously usage of 2 devices on the SPI bus. Maybe there is something wrong. Or it is just noise coming from the WiFi transmissions.

[gitpeut]

I didn't have the time I thought I had, but there is definitely something off in the CS behavior of the TFT. I had to disassemble my soldered version of the webradio and build it on breadboard again. This had the advantage that I could establish the fact that having the audio output next to the wifi antenna caused the clicks in my output. After having established proper working of the radio ( except the shimmer, reversal and blanks, which remained) I first made a kind of baseline with Sigrok and a 6 dollar logic analyze attached to ground, CS of the TFT and XCS of the VS1053. I uploaded and ran the graphicstest example of the ST7735 library. Of course XCS of VS1053 is silent, but CS of the TFT behaves as expected. High, with the occasional low for commands and data sent from the ESP32 to the graphics display. Just in case you forgot :-) CS is active low Then I uploaded the ESP32 webradio again, but this showed CS of the TFT almost contantly low, with some blibs around the second, when the time is updated.

I have changed pins ( from 5 to 13 ) on the ESP32, and have sampled the CS pin without the TFT attached, but the result remained the same. It seems the logic for the CS pin is confused by something, and is not caused by RF interference or other hardware issues, as the graphics test example shows normal behavior on the exact same hardware. I ran out of time, but this looks a promising direction of investigation. I hope anyone or Ed zelf has a breakthrough idea by now, but if not, any hint is appreciated.

[Edzelf]

Wow! Good job! It looks like the CS of the TFT is reversed completely. I will do the same measurement on my board.

[Edzelf]

Here my output of a logic analyzer. As you see the CS (channel 3) is normally high. Activity: once per second during about 2 msec. I used GPIO15 for CS. So the mystery is still not solved.

[gitpeut]

Ok. First a correction: I did not change the CS ping of the TFT from 5 to 13, but the XCS pin of the VS1053. It was nagging in my head all day, and tonight I verified. I also downloaded the newest software, and compiled it. Not surprisingly, this showed the same behaviour, no visible changes to the display code were made since May. Then I changed the CS pin of the TFT. I changed it from 15 to 12, and then it worked I verified with the logic analyzer: Correct :-). As expected also flicker disappeared and the volume bar stayed intact after changing volume. I changed back to GPIO15, and the same reverse logic showed on the logic analyzer and the screen showed flicker etc. As you said it looks like logic is reversed on pin 15. I am not aware pin 15 on the ESP32 has a special function, or why it is using reverse logic. I also checked the circuit diagram of my home built devboard, but apart from pin 15 being one of the JTAG connections, nothing is connected to it. Btw. GPIO12 and 13 are JTAG pins as well, and they work fine. I checked the ESP32 technical reference manual (chapter 4.3.2) , "The output signal can be inverted by setting the GPIO_FUNCx_OUT_INV_SEL bit" No idea why and where that would happen in the code and how to do it in Arduino. Any idea?

Anyway, it looks like I now have a working webradio :-). But I'm really curious about this funny logic inversion on pin 15.

[Edzelf]

It would be nice to know at what moment the polarity of pin 15 changes. If you are willing to do some testing, it would be great. I would do it myself if I only could reproduce the problem. Possible test: Configure pin 15 (in setup()) to OUTPUT and set it to LOW. See if it changes to HIGH after starting the radio. Hopefully you can figure out by looking at the debug output at what point in the software this happens. It may be necessary to insert delays in the program to locate the exact spot.

[gitpeut]

Yes, I am very curious myself so I will test. Don´t hold your breath, unfortunately my time is limited. I will keep you posted.

[gitpeut]

Ok. Result incomprehensible to me.

I connected GPIO15 to GPIO 21. set pin 21 to input. Made an extra task, and started that just after fillkeylist(). Changed dbgprint to also print millis().

Results are consistent. During startup of Wifi pin15 flips to LOW and afterwards shows the curious seemingly reverse logic. Ruled out WIfiMulti by skipping connectwifi() and hardcoding my wifi in, followed by an 8 second wait. In these 8 seconds pin 15 flips to LOW. I double checked with the logic analyzer, and confirmed the flip to low is in that period. With connectwifi() behavior is similar, result is the same: flicker.

.
.
.
 namespace_ID = FindNsID ( NAME ) ;                     // Find ID of our namespace in NVS
 fillkeylist() ;                                        // Fill keynames with all keys

 xTaskCreate (
    mon15,                                              // Task to handle special functions.
    "Mon15",                                            // name of task.
    2048,                                                 // Stack size of task
    NULL,                                                 // parameter of the task
    3,                                                    // priority of the task
    &xmon15 ) ;                                         // Task handle to keep track of created task
.
.
.
//************************************************************************************************
void mon15 ( void * parameter )
{
  int good = 1;
  int fcount  = 0;
  unsigned long int startmillis=0;
  char  badstring[32];

  dbgprint ( "Start mon15---------\n");

  pinMode( 21, INPUT );
  while ( good )
  {
    vTaskDelay ( 1 / portTICK_PERIOD_MS ) ;                       // Pause for a short time
    if ( good ){
      if ( !digitalRead( 21 ) ){
        ++fcount;
        if ( startmillis == 0 ) startmillis = millis();
        if ( fcount > 100 ){
          sprintf( badstring,"Pin 15 went BAD at %8lu\n", startmillis );

          dbgprint( badstring );
          good = 0;
        }
      }else{
        fcount = 0;
        startmillis = 0;
      }

  }
 } 
 vTaskDelete ( NULL ) ;                                          // Will never arrive here
}
...
in dbgprint:

 Serial.printf ( "D: %8lu ", millis() ) ;   
....
Serial Monitor output:

D:     4686 Command: toneha with parameter 0
D:     4690 Command: tonehf with parameter 1
D:     4694 Command: tonela with parameter 5
D:     4698 Command: tonelf with parameter 15
D:     4702 Command: volume with parameter 76
D:     4825 Slow SPI, Testing VS1053 read/write registers...
D:     5068 Fast SPI, Testing VS1053 read/write registers again...
D:     6199 endFillByte is 0
D:     6309 Connect to WiFi
D:     6391 Try WiFi dumdiedelum
D:    10252 Pin 15 went BAD at    10152

D:    11291 Connected to dumdiedelum
D:    11321 IP = 192.168.0.172
D:    14340 Start server for commands

[Edzelf]

Great Job! Thank you for that. Now see this.

[gitpeut]

Hmmm. Did not find that one. So why doesn't this happen in your setup?

Op do 28 jun. 2018 08:28 schreef Ed Smallenburg notifications@github.com:

Great Job! Thank you for that. Now see this https://www.esp32.com/viewtopic.php?t=5898.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Edzelf/ESP32-Radio/issues/100#issuecomment-400926494, or mute the thread https://github.com/notifications/unsubscribe-auth/AYkI43lm-MpLABJqNITFEvIcQQZeXWX0ks5uBHePgaJpZM4TTAsm .

[Edzelf]

Yes, that's a mystery since the start of this topic. I tried several ESP32s, no problem found. Maybe it has something to do with the router. I mean that the bug depends on a variable like channel, SSID, password, signal strength. Do you have the possibility to connect to a different router/network?

[gitpeut]

I tried connecting to a few different mobile hotspot names ( A, AB, ABA) on my phone. No difference in GPIO15 behavior. After reconnecting to my "normal" wifi GPIO15 still behaved badly. Obviously, there is almost no end in testing this. Any more suggestions? I will think about it some more, but at the moment I don't see any paths with possible success.

[Edzelf]

I examined source code of the libraries for a clue, but I did not find anything. Maybe it's a good idea to pass this problem to Iggr (espressif).

[gitpeut]

Yes, I have been looking in the Wifi code as well with the same non-result, and looked for similar bugs on https://github.com/espressif/arduino-esp32/issues, but I could not find anything that looked like this. I will soon leave and return on Sunday. I will open an issue then.

[gitpeut]

FYI: Opened a new issue https://github.com/espressif/arduino-esp32/issues/1568

[gitpeut]

Solved. Newest software helped. See espressif/arduino-esp32#1568. Very happy now :-) Thanks for the support.