IDF HVAC demo doesn’t work

[csann]

Building on OSX with latest xtensa and esp-idf. The project builds, flashes to ESP-WROVER-KIT v3, but screen remains blank. The ESP32_TFT_library builds and runs fine.

Terminal indicates program loaded and target was restarted. Nothing visible on screen.

• Did the build fail? Send part or all of the build log. No. Build did not fail.

I would be happy to troubleshoot this. Please give me suggestions where to look and what to try.

[MartyMacGyver]

I'm not exactly surprised... I have an old v1 board which had a different LCD.

There's another open bug report on this too (#3), I just haven't been working on this board lately (though for completeness I ought to - I'll be able to look at this more next Tuesday.)

[csann]

Thank you for this info. I just compared the schematics of the v1 and v3 boards. Besides the different LCD it also looks like they inverted the LCD backlight when they added an additional transistor. This probably means IO5 must be off to enable the backlight.

[csann]

I am almost done converting your hvac-demo to work with v3 using lovosevics ESP32_TFT_library. Just a few formatting problems remain.

[MartyMacGyver]

When your code is ready I'll be curious to see it - I just got a V3 (with the new ESP32-WROVER on board) today.

[csann]

(Attachment removed)

I zipped up my project. See below. It uses the esp32-tft framework.

On Oct 27, 2017, at 11:18 PM, Martin Falatic <notifications@github.com mailto:notifications@github.com> wrote:

When your code is ready I'll be curious to see it - I just got a V3 (with the new ESP32-WROVER on board) today.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub

[MartyMacGyver]

I got the attachment and then quickly deleted it from here because it contained your personal info (wifi info is what caught my eye). If you make this a github project be sure to scrub or omit sdkconfig as well as any build artifacts not part of the original project.

[csann]

Yea, that was stupid of me….wasn’t thinking. Thanks for reminding me.

On Oct 29, 2017, at 1:42 PM, Martin Falatic notifications@github.com wrote:

I got the attachment and then quickly deleted it from here because it contained your personal info (wifi info is what caught my eye). If you make this a github project be sure to scrub or omit sdkconfig as well as any build artifacts not part of the original project.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/MartyMacGyver/ESP32_Adafruit_ILI9341/issues/5#issuecomment-340284344, or mute the thread https://github.com/notifications/unsubscribe-auth/AB2NDeITAABsLvi40i4zU7w9y5ueQXneks5sxMcbgaJpZM4P9Hbq.

[MartyMacGyver]

No problem at all!

[saint-shark]

@csann can you share the code for version 3 board. My board just arrived and I wanted to test it

[exislow]

So I have got the current ESP32-WROVER-KIT v4 and have the same problems with the hvac-demo. The project compiles just fine $ make clean && make -j4 all && make flash monitor but the dispaly stays black. Instead I get the following output from the monitor:

rst:0x1 (POWERON_RESET),boot:0x1e (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:6660
load:0x40078000,len:11624
load:0x40080400,len:6684
entry 0x4008076c
I (28) boot: ESP-IDF v4.0-dev-837-g58df1d93b 2nd stage bootloader
I (28) boot: compile time 10:21:51
I (28) boot: Enabling RNG early entropy source...
I (34) boot: SPI Speed      : 40MHz
I (38) boot: SPI Mode       : DIO
I (42) boot: SPI Flash Size : 4MB
I (46) boot: Partition Table:
I (50) boot: ## Label            Usage          Type ST Offset   Length
I (57) boot:  0 nvs              WiFi data        01 02 00009000 00006000
I (65) boot:  1 phy_init         RF data          01 01 0000f000 00001000
I (72) boot:  2 factory          factory app      00 00 00010000 00100000
I (80) boot: End of partition table
I (84) esp_image: segment 0: paddr=0x00010020 vaddr=0x3f400020 size=0x0b200 ( 45568) map
I (109) esp_image: segment 1: paddr=0x0001b228 vaddr=0x3ffb0000 size=0x01de8 (  7656) load
I (112) esp_image: segment 2: paddr=0x0001d018 vaddr=0x40080000 size=0x00400 (  1024) load
0x40080000: _WindowOverflow4 at /Users/.../esp32/esp-idf/components/freertos/xtensa_vectors.S:1778

I (116) esp_image: segment 3: paddr=0x0001d420 vaddr=0x40080400 size=0x02bf0 ( 11248) load
I (129) esp_image: segment 4: paddr=0x00020018 vaddr=0x400d0018 size=0x182c4 ( 99012) map
0x400d0018: _stext at ??:?

I (169) esp_image: segment 5: paddr=0x000382e4 vaddr=0x40082ff0 size=0x052b0 ( 21168) load
0x40082ff0: timer_alarm_isr at /Users/.../esp32/esp-idf/components/esp32/esp_timer_esp32.c:274

I (183) boot: Loaded app from partition at offset 0x10000
I (183) boot: Disabling RNG early entropy source...
I (184) cpu_start: Pro cpu up.
I (187) cpu_start: Application information:
I (192) cpu_start: Project name:     testje
I (197) cpu_start: App version:      v1.01-11-gc3feb27-dirty
I (203) cpu_start: Compile time:     Jun 22 2019 10:21:54
I (209) cpu_start: ELF file SHA256:  b2b7fb0f4d566b56...
I (215) cpu_start: ESP-IDF:          v4.0-dev-837-g58df1d93b
I (222) cpu_start: Starting app cpu, entry point is 0x40080e84
0x40080e84: call_start_cpu1 at /Users/.../esp32/esp-idf/components/esp32/cpu_start.c:265

I (0) cpu_start: App cpu up.
I (232) heap_init: Initializing. RAM available for dynamic allocation:
I (239) heap_init: At 3FFAE6E0 len 00001920 (6 KiB): DRAM
I (245) heap_init: At 3FFB2E40 len 0002D1C0 (180 KiB): DRAM
I (251) heap_init: At 3FFE0440 len 00003AE0 (14 KiB): D/IRAM
I (258) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM
I (264) heap_init: At 400882A0 len 00017D60 (95 KiB): IRAM
I (270) cpu_start: Pro cpu start user code
I (288) cpu_start: Starting scheduler on PRO CPU.
I (0) cpu_start: Starting scheduler on APP CPU.
E (10289) task_wdt: Task watchdog got triggered. The following tasks did not reset the watchdog in time:
E (10289) task_wdt:  - IDLE0 (CPU 0)
E (10289) task_wdt: Tasks currently running:
E (10289) task_wdt: CPU 0: main
E (10289) task_wdt: CPU 1: IDLE1

Watchdog get triggered all the time. So basically the ESP32 restarts and the same output appears again.

Can anyone help me?

[MartyMacGyver]

I tried this myself with ESP-IDF v3.2.2 and indeed, it doesn't work.

What's happened is that much has changed since this demo was first created. As of today I've got a v4.1 board with the ESP32-WROVER-B on it and it was very little trouble to make the board work with Arduino-ESP32 + Adafruit-GFX-Library + Adafruit_ILI9341, using some of the latter's examples.

The kicker is, this was using the libraries as-is, installed directly via Arduino. Additionally, I was able to quickly experiment with using PSRAM as a backing buffer for a nice speed bump. There are certainly limitations (you can't really malloc() enough contiguously under Arduino-ESP32, which is why I used ps_malloc() there - I'm pretty sure you'd have more headroom on the IDF), but it was quick and easy, and I didn't need to convert everything to work solely with the IDF.

So, if/when I update or reissue this or something else, it'll likely be using the Arduino-ESP32 framework. The IDF is good and useful for many purposes, but for something that is more of a demonstrator than anything else, which already leverages libraries that are primarily intended for Arduino-like setups, it's just not worth chasing the ever-changing specs of the IDF to keep it in sync. Making such things work in the IDF is best left to those who have that particular need.

And one helpful tip for anyone who simply can't get the screen to light up - the backlight pin is active LOW:

#define TFT_BKLT 5
#if defined(TFT_BKLT)
  pinMode(TFT_BKLT, OUTPUT);
  digitalWrite(TFT_BKLT, LOW);
#endif

[MartyMacGyver]

There's a new demo in town.... see the demos/arduino-esp32/hvac_demo_v2 folder for the HVAC demo ported to Arduino-ESP32!

The fonts are a little different, but this works with the latest Adafruit GFX and Adafruit ILI9341 libraries, the latest ESP-WROVER-KITs, and I've gone through and updated most of the code to make it more useful as something to learn from, versus the original rote port that was both difficult to maintain and a pain to compile.

[exislow]

Actually this thread is about the IDF version of you demo, but your last two comments are about the arduino demo. Can you also provide a fixed IDF demo for the ESP-WROVER-KIT v4.2?

[MartyMacGyver]

I ended up rewriting the demo completely using Arduino-ESP32, and haven't had any bandwidth to convert that to ESP32 native.

I'm not finding great value in chasing the ever-changing IDF when the Arduino abstraction is pretty stable, and I'm not planning to maintain two different code bases for the same platform going forward. This was never meant to be a permanent driver-complete solution: the libraries underpinning the old demo became woefully outdated. Using more standard Arduino libraries avoids that problem.

I will look into adding some verbiage if there's an easy path to running the new demo on the IDF.

[exislow]

I understand your point and I really appreciate your (future) work! Just to explain shortly why some people might to rely on the IDF version: Using IDF commands, like amongst others, make menuconfig you can unleash some options of the ESP32 which are not available, if you program using the Arduino framework. Thus, I think it is also important to spread some knowledge regarding the IDF. There are already plenty graphical libraries/PoC for the Arduino framework of the ESP-WROVER-KIT v4 but almost none for IDF. So, thank you a lot in advance.

[MartyMacGyver]

When I adopted this code, it was simply to take an ESP8266 demo and run it on the ESP32. Most of the customizations to the core drivers are now part of the mainline Adafruit libs. The demo code itself was a mess, and my recent work was to make it more instructive and flexible, but it's still a toy project in that regard.

The IDF is indeed useful, but it's a niche and a bit of a pain... Everyone has to have their own unique SDK (Atmel, ST, Espressif, etc.) and at the time I did this it seemed like this would be a useful way to demo the ESP32... I'm not so sure this is appropriate to that task anymore. There's lots of other IDF-only examples out there that help people learn the IDF. Arduino-ESP32 is basically a system of shims over the IDF, and for the purpose of this demo the smart money for using this with the IDF is implementing a thin abstraction layer and leveraging existing, active libraries rather than creating Yet Another Variation of them.

What was a niche demo of mid-level and low level code became a demonstration of anti-patterns and how NOT to implement a low-level project, not to mention an exercise in why you shouldn't use an ILI9341 for anything you want to look sharp (no VSYNC, no double-buffering, etc.) Things that made sense at the time (because nobody had a good driver besides these odd "AS" forks) no longer make sense now.

At this point the project serves as a GUI demo with what I feel is better code around the mid-level graphics interfaces, and how to avoid reinventing wheels nobody wants to maintain once they reinvent them. If I end up doing an IDF version it'll become a demo of how to write an Arduino-like shim as well, because the real low-level ESP32 work is in the core libraries already. For now, that's an exercise for the user.

One more thing: I enjoyed rewriting the high-level code (and kicking the dead-end drivers to the curb) 50x more than anything I've done directly with the IDF in this project. The IDF work was constantly changing things just to keep up with the IDF code and structures, while trying to smooth out its rough edges. It helped me get some things fixed in the IDF and related tooling - things Arduino-ESP32 environment leverages as well - but it took a lot of time and effort for a platform that still has unnecessary hardware deficiencies and an annoying lack of usable I/O (I really hope they get things right with the next version of the ESP32).