MPU FAULT: Stacking error with lvgl on lv_timer_handler() #50226
Comments
|
Some things worth checking:
|
static bool lv_timer_exec(lv_timer_t * timer) {
[...]
if(timer->timer_cb && original_repeat_count != 0) timer->timer_cb(timer);
[...]
Looking now, I'm afraid it may be related to the compil-time warning :
Actually, I've registered my own draw area function Am I wrong on doing this way ? Do I must implement specific SSD1333 display driver API instead of having my own project C file doing so ? (As I'm a bit overwhelmed here by all this new stuff 😕 ) |
Maybe, but having both will create 2
I think in the long run its easier to add an out-of-tree driver (or in-tree if you can upstream) and amend your driver to the display subsystem library. It will be easier to follow/debug if you follow the current API contracts IMO. |
Well, not yet but in the end , you're right, nothing good comes along going against the framework :) |
|
Finally manage to port code to a dedicate zephyr driver :) I changed the code to align with samples/subsys/display/lvgl/src/main.c and got the following error on this : display_dev = DEVICE_DT_GET(DT_CHOSEN(zephyr_display));
The prj.conf didn't changed much : CONFIG_GPIO=y
CONFIG_DEBUG_OPTIMIZATIONS=y
CONFIG_NEWLIB_LIBC=y
CONFIG_DEBUG_THREAD_INFO=y
CONFIG_THREAD_STACK_INFO=y
CONFIG_HEAP_MEM_POOL_SIZE=50512
CONFIG_IDLE_STACK_SIZE=4096
CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=4096
CONFIG_MAIN_STACK_SIZE=4096
CONFIG_PRINTK=y
CONFIG_CONSOLE=y
CONFIG_RESET_ON_FATAL_ERROR=n
CONFIG_THREAD_NAME=y
# I2C
CONFIG_I2C=n
# SPI
CONFIG_SPI=y
CONFIG_SSD1333=y
CONFIG_DISPLAY=y
CONFIG_DISPLAY_LOG_LEVEL_ERR=y
CONFIG_LOG=y
CONFIG_LVGL=y
CONFIG_LV_MEM_CUSTOM=y
CONFIG_LV_Z_MEM_POOL_NUMBER_BLOCKS=8
CONFIG_LV_USE_LOG=y
CONFIG_LV_USE_LABEL=y
CONFIG_LV_USE_BTN=y
CONFIG_LV_USE_IMG=y
CONFIG_LV_FONT_MONTSERRAT_14=yAnd the overlay : /*
* nRF52840_dk SSD1333 (160x128)
*
* P0.28 (RESET) RES
* P0.5 (D5) DC (DATA/CMD)
* P0.27 (SCK) SCL
* P0.26 (MOSI) SDA
*/
/ {
chosen {
zephyr,display = &ssd1333;
};
};
&pinctrl {
spi3_default: spi3_default {
group1 {
psels = <NRF_PSEL(SPIM_SCK, 0, 5)>,
<NRF_PSEL(SPIM_MOSI, 0, 32)>,
<NRF_PSEL(SPIM_MISO, 0, 31)>;
};
};
spi3_sleep: spi3_sleep {
group1 {
psels = <NRF_PSEL(SPIM_SCK, 0, 5)>,
<NRF_PSEL(SPIM_MOSI, 0, 32)>,
<NRF_PSEL(SPIM_MISO, 0, 31)>;
low-power-enable;
};
};
};
&spi3 {
compatible = "nordic,nrf-spim";
status = "okay";
pinctrl-0 = <&spi3_default>;
pinctrl-1 = <&spi3_sleep>;
cs-gpios = <&gpio0 25 GPIO_ACTIVE_LOW>;
pinctrl-names = "default", "sleep";
ssd1333: ssd1333@0 {
compatible = "solomon,ssd1333";
label = "SSD1333";
spi-max-frequency = <20000000>;
reg = <0>;
cmd-data-pin = <&gpio0 30 GPIO_ACTIVE_LOW>;
reset-pin = < &gpio0 28 GPIO_ACTIVE_LOW >;
width = <160>;
height = <128>;
x-offset = <0>;
y-offset = <0>;
vcom = <0x19>;
gctrl = <0x35>;
};
};I forgot something I guess ? |
|
Are you sure the overlay is applied? Check |
|
It's not indeed, what should I do ? EDIT: I happened cmake |
|
Ok so now I packed everything up and.. I still have the same MPU Fault Staking error at the same point 😕 As a reminder, here is the new lvgl calls based on void view_lvgl() {
uint32_t count = 0U;
char count_str[11] = {0};
const struct device *display_dev;
lv_obj_t *hello_world_label;
lv_obj_t *count_label;
display_dev = DEVICE_DT_GET(DT_CHOSEN(zephyr_display));
if (!device_is_ready(display_dev)) {
printk("Device not ready, aborting test");
return;
}
if (IS_ENABLED(CONFIG_LV_Z_POINTER_KSCAN)) {
lv_obj_t *hello_world_button;
hello_world_button = lv_btn_create(lv_scr_act());
lv_obj_align(hello_world_button, LV_ALIGN_CENTER, 0, 0);
hello_world_label = lv_label_create(hello_world_button);
} else {
hello_world_label = lv_label_create(lv_scr_act());
}
lv_label_set_text(hello_world_label, "Hello world!");
lv_obj_align(hello_world_label, LV_ALIGN_CENTER, 0, 0);
count_label = lv_label_create(lv_scr_act());
lv_obj_align(count_label, LV_ALIGN_BOTTOM_MID, 0, 0);
lv_task_handler(); // <------------ Still crashing here at lv_timer.c:314: timer->timer_cb(timer);
display_blanking_off(display_dev);
while (1) {
if ((count % 100) == 0U) {
sprintf(count_str, "%d", count/100U);
lv_label_set_text(count_label, count_str);
}
lv_task_handler();
k_sleep(K_MSEC(10));
++count;
}
}Also, actual stack/heap size are defined like so : CONFIG_HEAP_MEM_POOL_SIZE=50512
CONFIG_IDLE_STACK_SIZE=4096
CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=4096
CONFIG_MAIN_STACK_SIZE=16384 |
|
@Linzdigr Have I understood correctly that you implemented a new display driver for SSD1333? Have you posted it somewhere? Have you been able to run the lvgl hello world on it? |
|
@brgl Yes, but it was working on his "standalone" c file form on my color OLED display. I didn't publicly posted the Zephyr driver for now since I wanted to make sure it works first :) Now I'm trying to do the job with Zephyr+LVGL as I didn't tried other way yet. |
|
Ok so, the Zephyr driver is working fine without LVGL with last modifications. As I switch back to the LVGL sample code, still the Stacking error comes 😕 Any idea ? |
|
Last tries:
No changes. |
How did you test the driver itself? Is it possible to share code for the driver? |
|
@pdgendt I tested my driver from the I'll fork the zephyr repo so I can show you, meanwhile, init of the display is done before the OS as expected (init/write/...), then no further call to any of the driver's function are done. It seems lvgl crashes before soliciting the driver layer. I just realized the stack size limit wasn't enough and independent from Thanks anyway ! Will do a PR for the driver when it's clear and clean :) |
When I'm trying to use lvgl along with Zephyr, I get the following:
I already tried to "play" with different
CONFIG_MAIN_STACK_SIZEandCONFIG_IDLE_STACK_SIZEvalues with no success.Here is the code I use to init and test the display
And the vars:
Environment:
Additional context
Unfortunately, there is not much about documentation on LVGL/Zephyr (https://docs.lvgl.io/master/get-started/os/zephyr.html) but I've seen some use case/examples without direct init call of the lvgl library but would like to use it "as is" (init on my own).
Thanks for your time !
The text was updated successfully, but these errors were encountered: