Should the width of screen be even number?

[stc1988]

When I changed width of screen (defines.ili9341.width) of manifest.json to odd number, then application repeated to reboot.

This video shows when I changed width to 75 from 80 in M5stickC.

IMG_97080370.MOV

I tried to change the width to some number and I found that this problem occurred in odd number.

[phoddie]

Yes, the driver expects that the width is an even number. The implementation of adaptInvalid won't work for an odd width. It is a misconfiguration to set it to an odd number.

[stc1988]

@phoddie
Thanks, I understood that this is limitation of implementation.

I'm try to add a support of M5StickC PLUS that screen size is 135 * 240. Is there an any solution for this screen size?

[phoddie]

In fact, my mistake. The ILI9341 driver has no width limitation when using 8 bit and 16 bit pixels. The adaptInvalid function is only used for 4 bit pixel formats. But, you are using 16 bit pixels.

Do you know where the crash is occurring? That might offer a hint as to a path to a solution. The easiest way to see the crash is to run an instrumented build (use -i instead of -d) which enables the gdb stub. Then you should be able to get a stack trace of the crash.

[stc1988]

I try to run instrumented build and got below log.

--- WARNING: GDB cannot open serial ports accessed as COMx
--- Using \\.\COM4 instead...
--- idf_monitor on \\.\COM4 115200 ---
--- Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---
ets Jun  8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 188777542, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0030,len:496
load:0x40078000,len:12828
load:0x40080400,len:3536
0x40080400: _init at ??:?

entry 0x400805d8

I'm no used to debug with gdb.Is Is it a something useful?

[phoddie]

No, unfortunately, that's not useful. That's just the ESP32 boot traces. I'm going to try to sort out GDB configuration on Windows.

I did try setting the ILI9341 width to 75 on Moddable Two. That works as expected - no crash -- with garbage in the uninitialized pixels. Here's a video. Are you able to duplicate that result?

[stc1988]

I dont' have Moddable Two. I did try setting the ILI9341 width to 75 on M5stack( driverRotation is 270).That works as expected.

On the other hand, I did try setting the ILI9341 height and I saw black screen.

[phoddie]

I dont' have Moddable Two.

Your loss. ;)

I did try setting the ILI9341 width to 75 on M5stack( driverRotation is 270).That works as expected.

It doesn't seem like the problem is that the display driver doesn't support an odd width.

Do you have another hypothesis?

[stc1988]

No, unfortunately, that's not useful. That's just the ESP32 boot traces. I'm going to try to sort out GDB configuration on Windows.
I did setup ModdableSDK in MacOS and tried the same instructions. It is simillar to Windows, I saw only boot trace.

[phoddie]

It looks like the instrumented build accidentally had serial output disabled when updating to IDF 4.3. They keep changing names... this change should get your instrumentation output back. I confirmed it here with a clean build of a clean tree. GDB works too. At least on macOS. Please let me know. If that works for you, we can figure out a clean fix...

[stc1988]

I changed config as you suggested and I saw ESP_LOG like below, but I didn't saw stacktrace.

I (32) cpu_start: Pro cpu up.
I (32) cpu_start: Starting app cpu, entry point is 0x40080fd4
0x40080fd4: call_start_cpu1 at /Users/satoshi/esp32/esp-idf/components/esp_system/port/cpu_start.c:141

I (0) cpu_start: App cpu up.
I (44) cpu_start: Pro cpu start user code
I (44) cpu_start: cpu freq: 240000000
I (44) cpu_start: Application information:
I (44) cpu_start: Project name:     xs_esp32
I (49) cpu_start: App version:      OS210826-76-g10cc52e1-dirty
I (55) cpu_start: Compile time:     Sep 29 2021 21:16:19
I (60) cpu_start: ELF file SHA256:  dae328dc04587e2f...
I (65) cpu_start: ESP-IDF:          v4.3.1-29-ge493a4c30e
I (70) heap_init: Initializing. RAM available for dynamic allocation:
I (76) heap_init: At 3FFAE6E0 len 00001920 (6 KiB): DRAM
I (81) heap_init: At 3FFB3548 len 0002CAB8 (178 KiB): DRAM
I (86) heap_init: At 3FFE0440 len 00003AE0 (14 KiB): D/IRAM
I (92) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM
I (97) heap_init: At 4008D1F8 len 00012E08 (75 KiB): IRAM
I (103) spi_flash: detected chip: gd
I (105) spi_flash: flash io: qio
I (109) cpu_start: Starting scheduler on PRO CPU.
I (0)"instruments key: Pixels drawn,Frames drawn,Network bytes read,Network bytes written,Network sockets,Timers,Files,Poco display list used,Piu command List used,SPI flash erases,System bytes free,CPU 0,CPU 1,Chunk used,Chunk available,Slot used,Slot available,Stack used,Stack available,Garbage collections,Keys used,Modules loaded,Parser used,Floating Point
instruments: 0,0,0,0,0,1,0,0,0,0,240652,1,3,5344,7168,5808,8192,2544,4096,8,0,0,0,5

[stc1988]

I tried release build. I got core dump log.

[stc1988]

When executed repeatedly, GDB started occasionally and stoped deffrent points.

I took logs, but I don't know what happened from these logs.
https://gist.github.com/stc1988/c0a3f790d15fe155e068e1a45c37ead6
https://gist.github.com/stc1988/d3f78d6f4181aa337e7d2ea1c4c93d2f
https://gist.github.com/stc1988/9886b2cc805d10d673d52d82eb380a42
https://gist.github.com/stc1988/d6ea744de23238313c3dc57b7bb5e264

[phoddie]

I tried release build. I got core dump log.

Right. The release build excludes the GDB stub since that shouldn't be deployed in production. Only the instrumented build has the GDB stub enabled.

When executed repeatedly, GDB started occasionally and stoped deffrent points.

I took logs, but I don't know what happened from these logs.

Interesting. It doesn't stop in the same place each time, but often in roughly the same neighborhood. That feels like memory corruption.

Maybe there is an inconsistent configuration? Or maybe there is a real out-of-bounds memory write? It would be helpful if I could reproduce the problem, even if it is not using the same hardware. Any ideas?

[phoddie]

Coming back to this, @stc1988:

• Any update from you?
• I found an M5Stick-C buried on my desk. @mkellner loaned it to me awhile ago. Unfortunately, it doesn't seem to want to power-on. I'm charging the battery. If I can get it to work, I'll try to reproduce the problem.
• The display is 160x80, according to the sticker on the back. That being the case, why are you setting it to 75??

[stc1988]

Sorry, no progress.

I'm try to add a support of M5StickC PLUS that screen size is 135 * 240. Is there an any solution for this screen size?

This is why I want to set odd number.Any odd number is fine.

[phoddie]

Oops... OK... that makes sense. I forget about the PLUS!