- ESP-ROM:esp32s3-20210327
- Build:Mar 27 2021
- rst:0x1 (POWERON),boot:0x3 (DOWNLOAD(USB/UART0))
- waiting for download
- ESP-ROM:esp32s3-20210327
- Build:Mar 27 2021
- rst:0x1 (POWERON),boot:0xb (SPI_FAST_FLASH_BOOT)
- SPIWP:0xee
- mode:DIO, clock div:2
- load:0x3fcd0108,len:0x1654
- load:0x403b6000,len:0xb7c
- load:0x403ba000,len:0x2f78
- entry 0x403b6248
- I (29) boot: ESP-IDF 121ddb87e-dirty 2nd stage bootloader
- I (30) boot: compile time 21:38:23
- I (30) boot: chip revision: 0
- I (32) boot.esp32s3: Boot SPI Speed : 40MHz
- I (37) boot.esp32s3: SPI Mode : DIO
- I (41) boot.esp32s3: SPI Flash Size : 8MB
- I (46) boot: Enabling RNG early entropy source...
- I (52) boot: Partition Table:
- I (55) boot: ## Label Usage Type ST Offset Length
- I (62) boot: 0 nvs WiFi data 01 02 00009000 00005000
- I (70) boot: 1 otadata OTA data 01 00 0000e000 00002000
- I (77) boot: 2 ota_0 OTA app 00 10 00010000 00200000
- I (85) boot: 3 ota_1 OTA app 00 11 00210000 00200000
- I (92) boot: 4 uf2 factory app 00 00 00410000 00040000
- I (100) boot: 5 user_fs Unknown data 01 81 00450000 003b0000
- I (107) boot: End of partition table
- I (112) boot: Defaulting to factory image
- E (116) esp_image: image at 0x410000 has invalid magic byte (nothing flashed here?)
- E (125) boot: Factory app partition is not bootable
- I (130) esp_image: segment 0: paddr=00010020 vaddr=3c120020 size=4a2f8h (303864) map
- I (214) esp_image: segment 1: paddr=0005a320 vaddr=3fc9a300 size=05638h ( 22072) load
- I (226) esp_image: segment 2: paddr=0005f960 vaddr=40374000 size=006b8h ( 1720) load
- I (226) esp_image: segment 3: paddr=00060020 vaddr=42000020 size=11461ch (1132060) map
- I (513) esp_image: segment 4: paddr=00174644 vaddr=403746b8 size=15c3ch ( 89148) load
- I (539) esp_image: segment 5: paddr=0018a288 vaddr=50000000 size=01010h ( 4112) load
- I (540) esp_image: segment 6: paddr=0018b2a0 vaddr=600fe000 size=00028h ( 40) load
- I (554) boot: Loaded app from partition at offset 0x10000
- I (554) boot: Disabling RNG early entropy source...
- I (568) opi psram: vendor id : 0x0d (AP)
- I (568) opi psram: dev id : 0x02 (generation 3)
- I (568) opi psram: density : 0x03 (64 Mbit)
- I (571) opi psram: good-die : 0x01 (Pass)
- I (576) opi psram: Latency : 0x01 (Fixed)
- I (581) opi psram: VCC : 0x01 (3V)
- I (586) opi psram: SRF : 0x01 (Fast Refresh)
- I (591) opi psram: BurstType : 0x01 (Hybrid Wrap)
- I (596) opi psram: BurstLen : 0x01 (32 Byte)
- I (602) opi psram: Readlatency : 0x02 (10 cycles@Fixed)
- I (608) opi psram: DriveStrength: 0x00 (1/1)
- W (612) PSRAM: DO NOT USE FOR MASS PRODUCTION! Timing parameters will be updated in future IDF version.
- I (623) spiram: Found 64MBit SPI RAM device
- I (627) spiram: SPI RAM mode: sram 80m
- I (632) spiram: PSRAM initialized, cache is in normal (1-core) mode.
- I (639) cpu_start: Pro cpu up.
- I (643) cpu_start: Starting app cpu, entry point is 0x40378450
- I (0) cpu_start: App cpu up.
- I (1075) spiram: SPI SRAM memory test OK
- I (1084) cpu_start: Pro cpu start user code
- I (1084) cpu_start: cpu freq: 240000000
- I (1084) cpu_start: Application information:
- I (1087) cpu_start: Project name: circuitpython
- I (1093) cpu_start: App version: 5.3.0-11827-gfcde108d0-dirty
- I (1099) cpu_start: Compile time: Apr 14 2022 21:38:17
- I (1106) cpu_start: ELF file SHA256: e4423d5ee5e26a92...
- I (1112) cpu_start: ESP-IDF: 121ddb87e-dirty
- I (1118) heap_init: Initializing. RAM available for dynamic allocation:
- I (1125) heap_init: At 3FCAB038 len 00034FC8 (211 KiB): D/IRAM
- I (1131) heap_init: At 3FCE0000 len 0000EE34 (59 KiB): STACK/DRAM
- I (1138) heap_init: At 3FCF0000 len 00008000 (32 KiB): DRAM
- I (1144) heap_init: At 600FE028 len 00001FD8 (7 KiB): RTCRAM
- I (1151) spi_flash: detected chip: generic
- I (1155) spi_flash: flash io: dio
- I (1160) sleep: Configure to isolate all GPIO pins in sleep state
- I (1166) sleep: Enable automatic switching of GPIO sleep configuration
- I (1174) coexist: coexist rom version e7ae62f
- I (1179) cpu_start: Starting scheduler on PRO CPU.
- I (0) cpu_start: Starting scheduler on APP CPU.
- I (10) gpio: GPIO[48]| InputEn: 1| OutputEn: 0| OpenDrain: 0| Pullup: 0| Pulldown: 0| Intr:0
- I (20) gpio: GPIO[0]| InputEn: 1| OutputEn: 0| OpenDrain: 0| Pullup: 0| Pulldown: 0| Intr:0
- I (1020) gpio: GPIO[48]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- I (1030) gpio: GPIO[0]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- I (1030) gpio: GPIO[1]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- I (1040) gpio: GPIO[2]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- I (1050) gpio: GPIO[3]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- I (1060) gpio: GPIO[4]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- I (1070) gpio: GPIO[5]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- I (1080) gpio: GPIO[6]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- I (1090) gpio: GPIO[7]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- I (1100) gpio: GPIO[8]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- I (1110) gpio: GPIO[9]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- I (1110) gpio: GPIO[10]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- I (1120) gpio: GPIO[11]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- I (1130) gpio: GPIO[12]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- I (1140) gpio: GPIO[13]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- I (1150) gpio: GPIO[14]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- I (1160) gpio: GPIO[15]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- I (1170) gpio: GPIO[16]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- I (1180) gpio: GPIO[17]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- I (1190) gpio: GPIO[18]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- I (1200) gpio: GPIO[21]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- I (1210) gpio: GPIO[38]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- I (1220) gpio: GPIO[45]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- I (1230) gpio: GPIO[46]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- I (1240) gpio: GPIO[47]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- I (1250) gpio: GPIO[48]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- E (1300) I2S: i2s_driver_uninstall(1957): I2S port 0 has not installed
- E (1300) I2S: i2s_driver_uninstall(1957): I2S port 1 has not installed
- E (1300) timer_group: timer_deinit(310): HW TIMER NEVER INIT ERROR
- E (1310) timer_group: timer_deinit(310): HW TIMER NEVER INIT ERROR
- E (1320) timer_group: timer_deinit(310): HW TIMER NEVER INIT ERROR
- E (1320) timer_group: timer_deinit(310): HW TIMER NEVER INIT ERROR
- I (1390) gpio: GPIO[0]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- I (1390) gpio: GPIO[1]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- I (1400) gpio: GPIO[2]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- I (1410) gpio: GPIO[3]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- I (1420) gpio: GPIO[4]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- I (1420) gpio: GPIO[5]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- I (1430) gpio: GPIO[6]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- I (1440) gpio: GPIO[7]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- I (1450) gpio: GPIO[8]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- I (1460) gpio: GPIO[9]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- I (1470) gpio: GPIO[10]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- I (1480) gpio: GPIO[11]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- I (1490) gpio: GPIO[12]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- I (1500) gpio: GPIO[13]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- I (1510) gpio: GPIO[14]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- I (1520) gpio: GPIO[15]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- I (1530) gpio: GPIO[16]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- I (1540) gpio: GPIO[17]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- I (1550) gpio: GPIO[18]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- I (1560) gpio: GPIO[21]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- I (1560) gpio: GPIO[38]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- I (1570) gpio: GPIO[45]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- I (1580) gpio: GPIO[46]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- I (1590) gpio: GPIO[47]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- I (1600) gpio: GPIO[48]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- E (1650) I2S: i2s_driver_uninstall(1957): I2S port 0 has not installed
- E (1650) I2S: i2s_driver_uninstall(1957): I2S port 1 has not installed
- W (6790) lcd_panel.rgb: Frame buffer is not an integer multiple of bounce buffers.
- W (6790) lcd_panel.rgb: Adjusted bounce buffer size from 10000 to 9600 pixels to fix this.
- ESP-ROM:esp32s3-20210327
- Build:Mar 27 2021
- rst:0x8 (TG1WDT_SYS_RST),boot:0xb (SPI_FAST_FLASH_BOOT)
- Saved PC:0x42110602
- SPIWP:0xee
- mode:DIO, clock div:2
- load:0x3fcd0108,len:0x1654
- load:0x403b6000,len:0xb7c
- load:0x403ba000,len:0x2f78
- entry 0x403b6248
- I (31) boot: ESP-IDF 121ddb87e-dirty 2nd stage bootloader
- I (31) boot: compile time 21:38:23
- I (32) boot: chip revision: 0
- I (34) boot.esp32s3: Boot SPI Speed : 40MHz
- I (39) boot.esp32s3: SPI Mode : DIO
- I (43) boot.esp32s3: SPI Flash Size : 8MB
- W (48) boot.esp32s3: PRO CPU has been reset by WDT.
- W (54) boot.esp32s3: APP CPU has been reset by WDT.
- I (59) boot: Enabling RNG early entropy source...
- I (65) boot: Partition Table:
- I (68) boot: ## Label Usage Type ST Offset Length
- I (76) boot: 0 nvs WiFi data 01 02 00009000 00005000
- I (83) boot: 1 otadata OTA data 01 00 0000e000 00002000
- I (90) boot: 2 ota_0 OTA app 00 10 00010000 00200000
- I (98) boot: 3 ota_1 OTA app 00 11 00210000 00200000
- I (105) boot: 4 uf2 factory app 00 00 00410000 00040000
- I (113) boot: 5 user_fs Unknown data 01 81 00450000 003b0000
- I (121) boot: End of partition table
- I (125) boot: Defaulting to factory image
- E (129) esp_image: image at 0x410000 has invalid magic byte (nothing flashed here?)
- E (138) boot: Factory app partition is not bootable
- I (143) esp_image: segment 0: paddr=00010020 vaddr=3c120020 size=4a2f8h (303864) map
- I (227) esp_image: segment 1: paddr=0005a320 vaddr=3fc9a300 size=05638h ( 22072) load
- I (234) esp_image: segment 2: paddr=0005f960 vaddr=40374000 size=006b8h ( 1720) load
- I (235) esp_image: segment 3: paddr=00060020 vaddr=42000020 size=11461ch (1132060) map
- I (523) esp_image: segment 4: paddr=00174644 vaddr=403746b8 size=15c3ch ( 89148) load
- I (549) esp_image: segment 5: paddr=0018a288 vaddr=50000000 size=01010h ( 4112) load
- I (550) esp_image: segment 6: paddr=0018b2a0 vaddr=600fe000 size=00028h ( 40) load
- I (564) boot: Loaded app from partition at offset 0x10000
- I (565) boot: Disabling RNG early entropy source...
- I (578) opi psram: vendor id : 0x0d (AP)
- I (578) opi psram: dev id : 0x02 (generation 3)
- I (578) opi psram: density : 0x03 (64 Mbit)
- I (582) opi psram: good-die : 0x01 (Pass)
- I (586) opi psram: Latency : 0x01 (Fixed)
- I (591) opi psram: VCC : 0x01 (3V)
- I (596) opi psram: SRF : 0x01 (Fast Refresh)
- I (601) opi psram: BurstType : 0x01 (Hybrid Wrap)
- I (607) opi psram: BurstLen : 0x01 (32 Byte)
- I (612) opi psram: Readlatency : 0x02 (10 cycles@Fixed)
- I (618) opi psram: DriveStrength: 0x00 (1/1)
- W (623) PSRAM: DO NOT USE FOR MASS PRODUCTION! Timing parameters will be updated in future IDF version.
- I (633) spiram: Found 64MBit SPI RAM device
- I (638) spiram: SPI RAM mode: sram 80m
- I (642) spiram: PSRAM initialized, cache is in normal (1-core) mode.
- I (649) cpu_start: Pro cpu up.
- I (653) cpu_start: Starting app cpu, entry point is 0x40378450
- I (0) cpu_start: App cpu up.
- I (1086) spiram: SPI SRAM memory test OK
- I (1094) cpu_start: Pro cpu start user code
- I (1094) cpu_start: cpu freq: 240000000
- I (1094) cpu_start: Application information:
- I (1097) cpu_start: Project name: circuitpython
- I (1103) cpu_start: App version: 5.3.0-11827-gfcde108d0-dirty
- I (1109) cpu_start: Compile time: Apr 14 2022 21:38:17
- I (1116) cpu_start: ELF file SHA256: e4423d5ee5e26a92...
- I (1122) cpu_start: ESP-IDF: 121ddb87e-dirty
- I (1128) heap_init: Initializing. RAM available for dynamic allocation:
- I (1135) heap_init: At 3FCAB038 len 00034FC8 (211 KiB): D/IRAM
- I (1141) heap_init: At 3FCE0000 len 0000EE34 (59 KiB): STACK/DRAM
- I (1148) heap_init: At 3FCF0000 len 00008000 (32 KiB): DRAM
- I (1154) heap_init: At 600FE028 len 00001FD8 (7 KiB): RTCRAM
- I (1162) spi_flash: detected chip: generic
- I (1166) spi_flash: flash io: dio
- I (1170) sleep: Configure to isolate all GPIO pins in sleep state
- I (1176) sleep: Enable automatic switching of GPIO sleep configuration
- I (1184) coexist: coexist rom version e7ae62f
- I (1189) cpu_start: Starting scheduler on PRO CPU.
- I (0) cpu_start: Starting scheduler on APP CPU.
- I (10) gpio: GPIO[0]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- I (10) gpio: GPIO[1]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- I (20) gpio: GPIO[2]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- I (30) gpio: GPIO[3]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- I (40) gpio: GPIO[4]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- I (50) gpio: GPIO[5]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- I (60) gpio: GPIO[6]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- I (70) gpio: GPIO[7]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- I (80) gpio: GPIO[8]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- I (90) gpio: GPIO[9]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- I (100) gpio: GPIO[10]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- I (110) gpio: GPIO[11]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- I (110) gpio: GPIO[12]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- I (120) gpio: GPIO[13]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- I (130) gpio: GPIO[14]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- I (140) gpio: GPIO[15]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- I (150) gpio: GPIO[16]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- I (160) gpio: GPIO[17]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- I (170) gpio: GPIO[18]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- I (180) gpio: GPIO[21]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- I (190) gpio: GPIO[38]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- I (200) gpio: GPIO[45]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- I (210) gpio: GPIO[46]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- I (220) gpio: GPIO[47]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- I (230) gpio: GPIO[48]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- E (280) I2S: i2s_driver_uninstall(1957): I2S port 0 has not installed
- E (280) I2S: i2s_driver_uninstall(1957): I2S port 1 has not installed
- E (280) timer_group: timer_deinit(310): HW TIMER NEVER INIT ERROR
- E (290) timer_group: timer_deinit(310): HW TIMER NEVER INIT ERROR
- E (300) timer_group: timer_deinit(310): HW TIMER NEVER INIT ERROR
- E (300) timer_group: timer_deinit(310): HW TIMER NEVER INIT ERROR
- I (370) gpio: GPIO[0]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- I (370) gpio: GPIO[1]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- I (380) gpio: GPIO[2]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- I (390) gpio: GPIO[3]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- I (390) gpio: GPIO[4]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- I (400) gpio: GPIO[5]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- I (410) gpio: GPIO[6]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- I (420) gpio: GPIO[7]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- I (430) gpio: GPIO[8]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- I (440) gpio: GPIO[9]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- I (450) gpio: GPIO[10]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- I (460) gpio: GPIO[11]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- I (470) gpio: GPIO[12]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- I (480) gpio: GPIO[13]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- I (490) gpio: GPIO[14]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- I (500) gpio: GPIO[15]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- I (510) gpio: GPIO[16]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- I (510) gpio: GPIO[17]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- I (520) gpio: GPIO[18]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- I (530) gpio: GPIO[21]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- I (540) gpio: GPIO[38]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- I (550) gpio: GPIO[45]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- I (560) gpio: GPIO[46]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- I (570) gpio: GPIO[47]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- I (580) gpio: GPIO[48]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
- E (630) I2S: i2s_driver_uninstall(1957): I2S port 0 has not installed
- E (630) I2S: i2s_driver_uninstall(1957): I2S port 1 has not installed
ESP32-S3 RGB LCD maximum throughput
-
- Posts: 9764
- Joined: Thu Nov 26, 2015 4:08 am
Re: ESP32-S3 RGB LCD maximum throughput
I'll see if I can dig a bit deeper, but one answer I have from the digital team is that the thing distributing PSRAM access permissions seems to be a non-configurable round-robin arbiter, so at this point I'm not sure if there's an easy hardware tweak to fix this. I'm still holding out hope for a complicated fix, but don't hold your breath please
-
- Posts: 8
- Joined: Mon Dec 13, 2021 3:49 pm
Re: ESP32-S3 RGB LCD maximum throughput
I am trying to use this solution as well as and I am facing problems due to its lack of information. So thank you for your information.
Please if you can answer some questions considering this solution:
1- What is the FPS achieved while changing the entire screen image?
2- do you have to keep flushing frames if no change is happening in the screen?
3- the LCD frame buffer is 800x400x2 = 768000 bytes. in case of 480x272x2 = 261120 bytes can it be located in internal RAM and the PSRAM problem will be solved ?
Thanks.
Please if you can answer some questions considering this solution:
1- What is the FPS achieved while changing the entire screen image?
2- do you have to keep flushing frames if no change is happening in the screen?
3- the LCD frame buffer is 800x400x2 = 768000 bytes. in case of 480x272x2 = 261120 bytes can it be located in internal RAM and the PSRAM problem will be solved ?
Thanks.
Last edited by Ali_Makhlouf on Mon Apr 11, 2022 5:38 am, edited 1 time in total.
-
- Posts: 9764
- Joined: Thu Nov 26, 2015 4:08 am
Re: ESP32-S3 RGB LCD maximum throughput
The issue is that if both the CPU and GDMA request access to the PSRAM, the bandwidth is divided 50-50 between the CPU cache and GDMA. This means that at best, you have the full bandwidth available to move data from the PSRAM to the LCD, but as soon as the CPU also wants to do something with the image (e.g. change it), the bandwith will be reduced to 50% of what it was. If the LCD needs more than that 50%, you'll get corruption.
The internal RAM has a much, much higher bandwidth, so if you use a framebuffer located there, I think any speed would work.
The internal RAM has a much, much higher bandwidth, so if you use a framebuffer located there, I think any speed would work.
Re: ESP32-S3 RGB LCD maximum throughput
Am running into similar issues with an 800x480 display running the ESP32-S3 LCD peripheral using the RGB dot clock interface.As I said, problems rise when the application code starts using the PSRAM for other purposes, as this seems to "stretch" the GDMA transactions, making the LCD peripheral loose data.
The only way to solve this would be some sort of hardware priority schemes which allow GDMA to complete its job without being interrupted.
When stationary and the processor is doing nothing else, the display looks fine. Whenever I am also doing some other processing (I think it is likely accessing PSRAM) the screen glitches. I have tried pixel clocks between 5 MHz and 30 MHz and the same effect occurs.
I have tried enabling the relax_on_idle, and now I am triggering a screen redraw only when the display data has changed (rather than continuously in “stream” mode). But that had no impact on the glitching.
I agree that some method of controlling priority or temporarily locking PSRAM access might be able to solve this. I’m eager to hear if anyone has suggestions or has successfully overcome this issue.
-
- Posts: 9764
- Joined: Thu Nov 26, 2015 4:08 am
Re: ESP32-S3 RGB LCD maximum throughput
Perhaps I can share something I've been working on. See attachment. It's a change to the esp_lcd driver that uses the CPU to copy data from PSRAM to an internal buffer, then sends data from that internal buffer. As copying happens in the CPU, you can use priorities etc to tweak the bandwidth a bit better, and as the buffer in internal memory is larger than the DMA fifo, it should be a bit more robust.
Simply take the attached file, unzip into the components folder of your project, and in your esp_lcd_rgb_panel_config_t struct, set bounce_buffer_size_px to a non-zero number (e.g. 1024*16).
This is not official code yet, but if your feedback is positive, we might make the effort to merge this in the main ESP-IDF driver.
Simply take the attached file, unzip into the components folder of your project, and in your esp_lcd_rgb_panel_config_t struct, set bounce_buffer_size_px to a non-zero number (e.g. 1024*16).
This is not official code yet, but if your feedback is positive, we might make the effort to merge this in the main ESP-IDF driver.
- Attachments
-
- lcd_component_pingpong_14apr2022.tgz
- (67.81 KiB) Downloaded 508 times
Re: ESP32-S3 RGB LCD maximum throughput
I spent today evaluating the code. Unfortunately the project I am trying to integrate it into is rather complex (CircuitPython) so it's difficult for me to give specific debugging feedback about these issues.
Here are my observations:
1. This code appears to use all the CPU cycles, so I turned off the interrupt after VSYNC and I manually trigger a refresh.
2. I still get glitches when the screen is redrawn.
3. At > 26 MHz, the vertical sync is really bad. (Perhaps this has something to do with my changes I implemented in #1.) 4. At 20 MHz pixel clock, my bouncing square is visible, but still glitchy. The glitches include a large square with some portion being yellow, and a "ghost" square that suggests the sync is being delayed. 5. I am getting some unpredictable crashes. Unfortunately I haven't been able to capture the debug log.
Note on my code: I am drawing a white 40x40 pixel square that is bouncing around the screen. Please note that these GIF images don't capture the actual speeds, but I hope they give some sense about the glitch behavior.
Screen is 800x480 16-bit parallel using RGB dot clock LCD peripheral with a ESP32-S3 devkit N8R8 running at 240 MHz with Octal SPI PSRAM.
Here are my observations:
1. This code appears to use all the CPU cycles, so I turned off the interrupt after VSYNC and I manually trigger a refresh.
2. I still get glitches when the screen is redrawn.
3. At > 26 MHz, the vertical sync is really bad. (Perhaps this has something to do with my changes I implemented in #1.) 4. At 20 MHz pixel clock, my bouncing square is visible, but still glitchy. The glitches include a large square with some portion being yellow, and a "ghost" square that suggests the sync is being delayed. 5. I am getting some unpredictable crashes. Unfortunately I haven't been able to capture the debug log.
Note on my code: I am drawing a white 40x40 pixel square that is bouncing around the screen. Please note that these GIF images don't capture the actual speeds, but I hope they give some sense about the glitch behavior.
Screen is 800x480 16-bit parallel using RGB dot clock LCD peripheral with a ESP32-S3 devkit N8R8 running at 240 MHz with Octal SPI PSRAM.
-
- Posts: 9764
- Joined: Thu Nov 26, 2015 4:08 am
Re: ESP32-S3 RGB LCD maximum throughput
Thanks for the feedback. Btw, one thing you could try to get it more stable is to mess with the aforementioned bounce_buffer_size_px variable, there seems to be some optimal value. Also, just curious, given the fact that you use CircuitPython, could it be that the other core is also actively accessing PSRAM while the display interrupt is running?
Re: ESP32-S3 RGB LCD maximum throughput
Thanks for the suggestions and for the code. I really appreciate the effort that your team is taking to try and get this to work, this LCD peripheral is a great capability to have.
I tried adjusting the size of the bounce_buffer_size_px and saw some odd behavior depending on the size. Sometimes nothing would display, sometimes the image would have missing rows. Sometimes it would crash very quickly. For example, using bounce_buffer_size_px = 10 * 1000, it would run for about 2 seconds and then restart.
I ended up using 16 * 1000 for the size of bounce_buffer_size_px for the demonstrations above on the 800 x 480 display.
Currently, the CircuitPython port for ESP32-S3 is only using one core. (To me this CircuitPython project is fairly complex to understand and debug, but if you have specific questions I will work to get the answer.)
If I use the code with the interrupts enabled, once the display was initiated, the system would hang. I assumed that this was because the display refresh interrupt kept stealing all the processor cycles. So, I disabled all the code lines that setup the interrupt on VSYNC. To refresh the display I added a "flush_buffer" function to flush the Cache and call lcd_rgb_panel_start_transmission (see images in the previous post).
I just changed my "flush_buffer" to flush the cache and call lcd_rgb_panel_restart_transmission (instead of start_transmission). It is still out of sync, but the weird giant boxes are gone. That's a step forward.
In the lcd_rgb_panel_restart_transmission I added a "esp_rom_delay_us(1);" after the gdma_start, but it had no effect.
Perhaps there is something that is slowing down the transmission after it starts. I'll need to dig in further to understand the bounce code that you added. Any suggestions are welcome.
Debugging update:
I found a way to capture the full Debug log after a crash. Here is what happens when I set bounce_buffer_size_px = 10 * 1000 and the system restarts after about 2 seconds after the display starts. See line 144 for the restart. I don't think it is a power dip, but I could be wrong. I have both USB ports connected to my MacBook which is powered by the wall plug.
I tried adjusting the size of the bounce_buffer_size_px and saw some odd behavior depending on the size. Sometimes nothing would display, sometimes the image would have missing rows. Sometimes it would crash very quickly. For example, using bounce_buffer_size_px = 10 * 1000, it would run for about 2 seconds and then restart.
I ended up using 16 * 1000 for the size of bounce_buffer_size_px for the demonstrations above on the 800 x 480 display.
Currently, the CircuitPython port for ESP32-S3 is only using one core. (To me this CircuitPython project is fairly complex to understand and debug, but if you have specific questions I will work to get the answer.)
If I use the code with the interrupts enabled, once the display was initiated, the system would hang. I assumed that this was because the display refresh interrupt kept stealing all the processor cycles. So, I disabled all the code lines that setup the interrupt on VSYNC. To refresh the display I added a "flush_buffer" function to flush the Cache and call lcd_rgb_panel_start_transmission (see images in the previous post).
I just changed my "flush_buffer" to flush the cache and call lcd_rgb_panel_restart_transmission (instead of start_transmission). It is still out of sync, but the weird giant boxes are gone. That's a step forward.
In the lcd_rgb_panel_restart_transmission I added a "esp_rom_delay_us(1);" after the gdma_start, but it had no effect.
Perhaps there is something that is slowing down the transmission after it starts. I'll need to dig in further to understand the bounce code that you added. Any suggestions are welcome.
Debugging update:
I found a way to capture the full Debug log after a crash. Here is what happens when I set bounce_buffer_size_px = 10 * 1000 and the system restarts after about 2 seconds after the display starts. See line 144 for the restart. I don't think it is a power dip, but I could be wrong. I have both USB ports connected to my MacBook which is powered by the wall plug.
Re: ESP32-S3 RGB LCD maximum throughput
One more positive update!
Now that using "restart_transmission" was showing some progress, I decided to add back the interrupts (like the original code). For some reason, the code doesn't hang anymore (not sure why this is different from my earlier trials).
Now with a 24 MHz dot clock and a bounce_buffer_size_px = 1000 * 18, this is a very positive step!
I can now demonstrate the bouncing box (white 40x40 pixels). Also, I added four red squares ( red20x20 pixels) in the corners so I could check whether the screen was synced properly.
This is looking very good! I think using "start_transmission" to refresh the screen was causing my issues. There are still some mysteries about why it wasn't working previously. I will do a little more experimenting and will report back if I can understand any more about the "bounce_buffer" and what are the important aspects about it to get it to work.
Many thanks for sharing this code for evaluation!
Now that using "restart_transmission" was showing some progress, I decided to add back the interrupts (like the original code). For some reason, the code doesn't hang anymore (not sure why this is different from my earlier trials).
Now with a 24 MHz dot clock and a bounce_buffer_size_px = 1000 * 18, this is a very positive step!
I can now demonstrate the bouncing box (white 40x40 pixels). Also, I added four red squares ( red20x20 pixels) in the corners so I could check whether the screen was synced properly.
This is looking very good! I think using "start_transmission" to refresh the screen was causing my issues. There are still some mysteries about why it wasn't working previously. I will do a little more experimenting and will report back if I can understand any more about the "bounce_buffer" and what are the important aspects about it to get it to work.
Many thanks for sharing this code for evaluation!
-
- Posts: 9764
- Joined: Thu Nov 26, 2015 4:08 am
Re: ESP32-S3 RGB LCD maximum throughput
Nice to see it works! I don't think I use restart_transmission in my testcase and it doesn't really make sense anyway in a situation where you have a continuously-scanned LCD; I'll see if the logic there needs changing or something.
Who is online
Users browsing this forum: No registered users and 126 guests