The MAX_IMAGE_WIDTH parameter resets the CPU without warning

[rtek1000]

Only raise issues for problems with the library and/or provided examples. Post questions, comments and useful tips etc in the "Discussions" section.

To minimise effort to resolve issues the following should be provided as a minimum:

1. A description of the problem and the conditions that cause it to occur

   • If the image is larger than the MAX IMAGE WIDTH parameter, it causes the CPU to restart without warning.

2. IDE (e.g. Arduino or PlatformIO)

   • Arduino IDE 1.8.19

3. TFT_eSPI library version (try the latest, the problem may have been resolved!) from the Manage Libraries... menu

   • Is the latest.

4. Board package version (e.g. 2.0.3) available from the Boards Manager... menu

5. Procesor, e.g RP2040, ESP32 S3 etc

   • ESP32 DEV KIT V1

6. TFT driver (e.g. ILI9341), a link to the vendors product web page is useful too.

   • SSD1963 (800x480, 7 inch)

7. Interface type (SPI or parallel)

   • Parallel

Plus further information as appropriate to the problem:

1. TFT to processor connections used
2. A zip file containing your setup file (just drag and drop in message window - do not paste in long files!)
3. A zip file containing a simple and complete example sketch that demonstrates the problem but needs no special hardware sensors or libraries.
4. Screen shot pictures showing the problem (just drag and drop in message window)

The idea is to provide sufficient information so I can setup the exact same (or sufficiently similar) scenario to investigate and resolve the issue without having a tedious ping-pong of Q&A.

DO NOT paste code directly into the issue. To correctly format code put three ticks ( ` character on key next to "1" key) at the start and end of short pasted code segments to avoid format/markup anomolies. See here:

Example output:

• The display just flashes one line.

Limit alert suggestion:

void loop()
{
  int16_t rc = png.openFLASH((uint8_t *)fish, sizeof(fish), pngDraw);
  if (rc == PNG_SUCCESS) {
    Serial.println("Successfully opened png file");
    Serial.printf("image specs: (%d x %d), %d bpp, pixel type: %d\n", png.getWidth(), png.getHeight(), png.getBpp(), png.getPixelType());

    if (png.getWidth() <= MAX_IMAGE_WIDTH) {
      tft.startWrite();
      uint32_t dt = millis();
      rc = png.decode(NULL, 0);
      Serial.print(millis() - dt); Serial.println("ms");
      tft.endWrite();
    } else {
      Serial.print("MAX_IMAGE_WIDTH limitation: ");
      Serial.print(MAX_IMAGE_WIDTH);
      Serial.println(" pixels\r\n");
    }

    // png.close(); // not needed for memory->memory decode
  } else {
    Serial.println("PNG_MAX_BUFFERED_PIXELS limitation?");
    Serial.println("- Check the file /libraries/PNGdec/src/PNGdec.h\r\n");
  }

  delay(3000);
  tft.fillScreen(random(0x10000));
}

• If "png.openFLASH() returns PNG_SUCCESS", but "png.getWidth() > MAX_IMAGE_WIDTH":

Serial monitor:

10:49:40.613 -> Successfully opened png file 10:49:40.647 -> image specs: (800 x 480), 8 bpp, pixel type: 6 10:49:40.647 -> MAX_IMAGE_WIDTH limitation: 240 pixels

• If "png image Width < MAX_IMAGE_WIDTH", but "png.openFLASH() does not return PNG_SUCCESS"

Serial monitor:

10:52:19.799 -> PNG_MAX_BUFFERED_PIXELS limitation? 10:52:19.799 -> - Check the file /libraries/PNGdec/src/PNGdec.h

---

• Ideally, the TFT_eSPI library could handle the MAX_IMAGE_WIDTH limit on its own without restarting the CPU, in the same way that the PNGdec library does.
• Depending on the user having error handling in the sketch can harm the library 'image'

[rtek1000]

Related: https://github.com/Bodmer/TFT_eSPI/issues/3185

[Bodmer]

So if I understand correctly adjusting the value in the sketch works: https://github.com/Bodmer/TFT_eSPI/blob/master/examples/PNG%20Images/Flash_PNG/Flash_PNG.ino#L25

But if the image is more that 640 pixels wide the the PNGdec library must also be updated here: https://github.com/bitbank2/PNGdec/blob/master/src/PNGdec.h#L52C1-L53C44

[rtek1000]

There are 2 problems, the first is the lack of warning from the TFT_eSPI library, and as a result the uC restarts. The other is the limitation of the PNGdec library, but the library already handles this silently and decoding does not occur.