At the base, some TFT_eSPI or Espressif code is wrong. I think https://github.com/Bodmer/TFT_eSPI/issues/3329#issuecomment-2808875061 is close to a good explanation.
Arduino cores before 2.0.16 did not define REG_SPI_BASE, so TFT_eSPI defines it in this case to always DR_REG_SPI2_BASE as a bugfix. Arduino cores after 2.0.16 do define it to
#define REG_SPI_BASE(i) (((i)>=2) ? (DR_REG_SPI2_BASE + (i-2) * 0x1000) : (0))
which, together with the definition of what’s used for i is FSPI and
#define FSPI 0
gives a null pointer (0) instead of DR_REG_SPI2_BASE. This crashes execution.
So it seems like the definition of FSPI is wrong for ESP32S3 or TFT_eSPI should be using HSPI not FSPI as the SPI_PORT.
We ““fixed”” it by downgrading the platform in the platformio.ini to use an older Arduino core, where TFT_eSPI uses the right REG_SPI_BASE value.
Other ports suggest that it should also work on the newer Arduino cores and ESP32S3 if you define the USE_HSPI_PORT macro to make that happen.
So, if you want another test:
[env:esp32-s3-devkitc-1]
; uses Arduino-ESP32 2.0.17
platform = espressif32@6.11.0
board = esp32-s3-devkitc-1
framework = arduino
board_build.arduino.memory_type = qio_qspi
board_build.flash_mode = qio
board_build.psram_type = qspi
board_upload.flash_size = 16MB
board_build.partitions = default_16MB.csv
; PSRAM + bugfix against TFT_eSPI/issues/3329 on newer Arduino cores
board_build.extra_flags =
-DBOARD_HAS_PSRAM
-DUSE_HSPI_PORT
monitor_speed = 115200
build_type = debug
monitor_filters =
esp32_exception_decoder