Describe the problem
Arduino_H7_Video.cpp guards its entire LVGL integration behind #if __has_include("lvgl.h"):
|
#if __has_include ("lvgl.h") |
|
#include "lvgl.h" |
|
#endif |
|
#if __has_include ("lvgl.h") |
|
#if __has_include("lvgl.h") |
|
#if __has_include("lvgl.h") |
Because __has_include uses a quoted form, it resolves against the compiling translation unit's include path. The Arduino IDE places all libraries on one flat include path, so the check always succeeds. PlatformIO compiles each library in an isolated environment, so unless LVGL's directory is explicitly added to the global include path, the check evaluates false for Arduino_H7_Video.cpp even when the sketch itself includes lvgl.h and links against LVGL successfully.
The failure is silent. begin() initialises SDRAM and the video bridge, skips all LVGL setup, and falls through to return 0 — indicating success. There is no diagnostic.
Symptoms
The first lv_obj_create(lv_scr_act()) hard faults. Captured state:
CFSR = 0x00008200 (BFARVALID | PRECISERR)
HFSR = 0x40000000 (FORCED)
BFAR = 0x84EB3EBC
Faulting PC in block_size (lv_tlsf.c:384), called from block_locate_free
p tlsf returns 0x0 — LVGL's heap was never initialised
The garbage pointer is uninitialised memory read through a null TLSF control block, not heap corruption. On the Giga this manifests as the red 4-slow/4-fast LED pattern with no serial output.
To reproduce
Build any LVGL sketch for the GIGA R1 WiFi under PlatformIO without adding LVGL to the global include path.
🐛 Step Arduino_H7_Video::begin() — execution jumps from line 99 directly to return 0 at line 167.
Environment
Board: Arduino GIGA R1 WiFi + GIGA Display Shield
Core: framework-arduino-mbed 4.2.4 (PlatformIO, platform ststm32 19.1.0)
LVGL: 8.3.11 (also reproduced on 9.5.0)
Additional context
The fix I suggested is to either use __has_include(<lvgl.h>), or return a distinct non-zero error code when the LVGL block is compiled out so callers can detect it. A #warning at compile time would also have made this immediately diagnosable.
Workaround
build_flags = -I .pio/libdeps/<env>/lvgl@8.3.11
Related
Describe the problem
Arduino_H7_Video.cppguards its entire LVGL integration behind#if __has_include("lvgl.h"):ArduinoCore-mbed/libraries/Arduino_H7_Video/src/Arduino_H7_Video.cpp
Lines 34 to 36 in b4ad4e7
ArduinoCore-mbed/libraries/Arduino_H7_Video/src/Arduino_H7_Video.cpp
Line 39 in b4ad4e7
ArduinoCore-mbed/libraries/Arduino_H7_Video/src/Arduino_H7_Video.cpp
Line 103 in b4ad4e7
ArduinoCore-mbed/libraries/Arduino_H7_Video/src/Arduino_H7_Video.cpp
Line 242 in b4ad4e7
Because
__has_includeuses a quoted form, it resolves against the compiling translation unit's include path. The Arduino IDE places all libraries on one flat include path, so the check always succeeds. PlatformIO compiles each library in an isolated environment, so unless LVGL's directory is explicitly added to the global include path, the check evaluates false forArduino_H7_Video.cppeven when the sketch itself includeslvgl.hand links against LVGL successfully.The failure is silent.
begin()initialises SDRAM and the video bridge, skips all LVGL setup, and falls through to return0— indicating success. There is no diagnostic.Symptoms
The first
lv_obj_create(lv_scr_act())hard faults. Captured state:CFSR = 0x00008200 (BFARVALID | PRECISERR)
HFSR = 0x40000000 (FORCED)
BFAR = 0x84EB3EBC
Faulting PC in block_size (lv_tlsf.c:384), called from block_locate_free
p tlsf returns 0x0 — LVGL's heap was never initialised
The garbage pointer is uninitialised memory read through a null TLSF control block, not heap corruption. On the Giga this manifests as the red 4-slow/4-fast LED pattern with no serial output.
To reproduce
Build any LVGL sketch for the GIGA R1 WiFi under PlatformIO without adding LVGL to the global include path.
🐛 Step
Arduino_H7_Video::begin()— execution jumps from line 99 directly to return 0 at line 167.Environment
Board: Arduino GIGA R1 WiFi + GIGA Display Shield
Core: framework-arduino-mbed 4.2.4 (PlatformIO, platform ststm32 19.1.0)
LVGL: 8.3.11 (also reproduced on 9.5.0)
Additional context
The fix I suggested is to either use
__has_include(<lvgl.h>), or return a distinct non-zero error code when the LVGL block is compiled out so callers can detect it. A#warningat compile time would also have made this immediately diagnosable.Workaround
build_flags = -I .pio/libdeps/<env>/lvgl@8.3.11Related