Rotary encoder interruption issue with SPI display on some GPIOs

[tistructor]

Hi,

I built a custom board rp2040 and it works correctly.

I'm testing with an SPI ST7735 display (Esplora) with a mechanical rotary encode button as well.

The display works correctly in SPI with the library
TFT_eSPI.

Mechanical encoder also works well if I do the test without a display and it also works correctly with the display but only on some pins such as D0 (A), D1 (B) and D2 (button).
The button does not have an interrupt routine that handles it.

However, if I use pins, for example from D20 to D29, unbalance the count when turning the knob.

It also jumps 3 or 4 randomly by 1 or more units, both in one direction and in the other direction of rotation.

It's like bounces are happening but I checked with an oscilloscope and everything is correct.

The encoder has circuitry that filters contact bounces.

I tried to reduce the speed of the SPI bus up to 1MHz but the problem remains.

I don't understand what such behavior could be due to.

I attach the code I use for the test.
Together there is User_setup.h but it is for reference only to set up the TFT_eSPI library

Encoder_GitHub.zip

[tistructor]

I did a further test with an I2C 1306 display with U8G2 I2C library in HW and in this case the encoder works correctly on all gpios or at least on some that previously gave problems.
I haven't tested all GPIOs.

[earlephilhower]

Moved to a discussion because this looks like a HW issue that's not core related or reproducible outside your physical setup. If you can find an MCVE that runs w/o special HW and produces logic analyzer outputs we can look at, we can take a deeper look. Otherwise, we're at the guesswork stage here.

In general the GPIOs are all identically handled (except for the LED on the PicoW). It's a single 32-bit register in the MCU and we just mask off specific pins. Even the GPIOs that are also connected to the ADC, for SIO (normal digital I/O) are handled this way. So the upper pins, assuming no analogReads on them, are identical internally to the lower ones.

[tistructor]

Well,
I'll see what I can do.
I have rp2040 modules not made by me.
The model is this VCC-GND YD-RP2040.

I do tests on this model with related encoder logic signals and increment values ​​recorded via USB serial.

Thanks for the reply.

[tistructor]

I did the same tests on the YD-RP2040 board as on my custom board and the result is the same.

Without spi routines for the display the encoder works correctly.

If I add the encoder display functions it starts to have problems.

I noticed if I only initialize the display without then transferring data to it the encoder works correctly but when I continuously print text on the display for example the encoder starts to not work correctly.

I recorded the encoder signals A and B with an oscilloscope (10 increments)
But on the serial console I get much more and incorrect ones.

Only the values ​​when a change occurs are printed on the serial console.

I attach the images.

test.zip

[tistructor]

I did the same test but without SPI.
The result is correct.

I attach images:


Encoder_print_noSPI.zip

[tistructor]

There are no bounces on the A and B signals which could generate errors in both tests.

But with the display initialized with continuous writing of text the encoder goes a little crazy.

I don't feel like the code I use is wrong, I've used it many times on AVR and have never encountered such problems.

Even with another RP2040 board with SPI display with software management, encoder works correctly.

[tistructor]

I might do one more test.

I create a quadrature signal A and B with two GPIOs and connect them to the encoder reading GPIOs so I can check if in the real case there could be any disturbances on the signal.

[tistructor]

In the simulation of the two quadrature signals generated via software and applied to the two GPIOs with interrupts I do not encounter any problems.

In this case, however, the signals are read via interrupt but not when data is being transferred to the display.

[tistructor]

Software quadrature signal

/*

  Encoder

      Test Display ST7735R Esplora spi and rotary encoder

*/
#include "inputControl.h"
#include <TFT_eSPI.h> // Hardware-specific library
#include <SPI.h>


TFT_eSPI tft = TFT_eSPI();       // Invoke custom library

// encoder
const int pinChA  = D26;
const int pinChB  = D27;
const int pinP    = D28;

// quadrature signal
const int pinA  = D22;
const int pinB  = D23;

uint32_t timer;
uint32_t tQuadrature;


void setup(void) {
  Serial.begin(115200);
  Serial.print("Test TFT ST7735 Esplora + Encoder");

  // Use this initializer if you're using a 1.8" TFT
  tft.init(INITR_GREENTAB2);   // initialize a ST7735S chip
  tft.setRotation(1);
  tft.fillScreen(TFT_BLACK);
  // quadrature
  pinMode(pinA, OUTPUT);
  pinMode(pinB, OUTPUT);
  digitalWrite(pinA, LOW);
  digitalWrite(pinB, LOW);
  // Encoder
  initIncrementalEncoder(pinChA, pinChB, pinP, false);
  Serial.println("Initialized");


}

void loop(void) {

  draw();

}



void draw(void) {
  timer = millis();
  if (timer - tQuadrature < 500) digitalWrite(pinA, HIGH);
  else if (timer - tQuadrature < 1000) digitalWrite(pinB, HIGH);
  else if (timer - tQuadrature < 1500) digitalWrite(pinA, LOW);
  else if (timer - tQuadrature < 2000) digitalWrite(pinB, LOW);
  else tQuadrature = timer;

  static bool flag = true;
  tft.setTextColor(TFT_YELLOW, TFT_BLACK);
  tft.setTextSize(2);
  tft.setCursor(0, 0);
  tft.println("# ALL TEST #");

  tft.drawString("SWP -> ", 0, 48, 1);
  //  tft.print("SWP -> ");
  if (readSwEncoder() == B_ON)  {
    if (!flag) {
      tft.drawString("OFF ", 90, 48, 1);
      flag = true;
    }
  }
  else {
    if (flag) {
      tft.drawString("ON ", 90, 48, 1);
      flag = false;
    }
  }

  tft.setCursor(0, 64);
  tft.print("POS -> ");
  static int32_t last_pos = -1;
  int32_t pos = getEncoderPosition();
  if (pos != last_pos) {
    tft.setCursor(90, 64);
    tft.setTextColor(TFT_BLACK, TFT_BLACK);
    tft.print(last_pos);
    tft.setTextColor(TFT_YELLOW, TFT_BLACK );
    tft.setCursor(90, 64);
    tft.print(getEncoderPosition());
    last_pos = pos;
    Serial.print("pos: "); Serial.println(pos);
  }
}

[tistructor]

I think it's a nuisance problem.

I made the signal in quadrature with an st32 and connected pins A and B to the rp2040 and I don't get incorrect values ​​in the counting with SPI display active.

It's a hardware problem that I need to identify.

[earlephilhower]

Good debugging! Signal timing/integrity issues are always real pains!

[tistructor]

I solved it via software so as to ignore pulses on signals A and B that were too close together in time.
I consider good signals on the same gpio only if there are at least 500uS between them.

In this way bounces are eliminated.

This is the part of code inserted in the ISR that manages the two channels A and B:

/*
   encoderChA(): isr for channel A

*/
void encoderChA() {
  uint8_t _index;
  static uint32_t tLast = 0;
  if (micros() > tLast+500) {
    _index = digitalRead(_pinCHA) << 1;
    _index |= digitalRead(_pinCHB);
    if (_dir)_encoderPosition += tabA[_index];
    else _encoderPosition -= tabA[_index];
    tLast = micros();
  }
}

I check with an oscilloscope where these bounces occur which I was unable to identify with a quick analysis.

Perhaps bounces exceed the 0.2V hysteresis of the rp2040's GPIOs, generating erroneous interrupt pulses.

Or more precisely with the noise of the SPI bus I exceed the 0.2V of the GPIO hysteresis with the noise, generating false interruptions.