search

lvgl-micropython / lvgl_micropython

LVGL module for MicroPython
MIT License
62 stars 19 forks source link

Use _thread module will cause system crash #91

Closed jd3096-mpy closed 1 week ago

jd3096-mpy commented 1 month ago 
import task_handler
th = task_handler.TaskHandler()

Must be run or LVGL will not start. But when I use _thread module it will cause system crash Here is the simple test code:

# Initialize display
display.init()

import task_handler
th = task_handler.TaskHandler()

scrn = lv.screen_active()
scrn.set_style_bg_color(lv.color_hex(0x000000), 0)

label = lv.label(scrn)
label.set_text('HELLO WORLD!')
label.align(lv.ALIGN.CENTER, 0, -50)

import _thread
import time
def test():
    while 1:
        print('this will cause crash!')
        time.sleep(1)
_thread.start_new_thread(test, ())

It seems _thread and task_handle only one can be run. How to use _thread module in this case？ Should I modify task_handle.py or choose another way like timer or uasyncio？

kdschlosser commented 1 month ago

what is the board you are using this on?

jd3096-mpy commented 1 month ago

what is the board you are using this on?

My board is esp32s3 wroom N8R8 with oct psram

I make firmware by this command: python3 make.py esp32 clean BOARD=ESP32_GENERIC_S3 BOARD_VARIANT=SPIRAM_OCT DISPLAY=st7789

And here is the repl debug print:

LVGL test script executed successfully
this will cause crash!

A fatal error occurred. The crash dump printed below may be used to help
determine what caused it. If you are not already running the most recent
version of MicroPython, consider upgrading. New versions often fix bugs.

To learn more about how to debug and/or report this crash visit the wiki
page at: https://github.com/micropython/micropython/wiki/ESP32-debugging

LVGL MPY version : 1.23.0 on 2024-08-05
IDF version : 11eaf41b
Machine     : Generic ESP32S3 module with Octal-SPIRAM with ESP32S3

Guru Meditation Error: Core  1 panic'ed (LoadProhibited). Exception was unhandled.

Core  1 register dump:
PC      : 0x4037e47a  PS      : 0x00060930  A0      : 0x820af159  A1      : 0x3fcc1c80  
A2      : 0x3fcc13f8  A3      : 0xffffffff  A4      : 0x3c2155b8  A5      : 0x00000001  
A6      : 0x0001000e  A7      : 0x3fcc13f8  A8      : 0x00000001  A9      : 0x00000048  
A10     : 0x00000002  A11     : 0x00000000  A12     : 0x3fcc1eb4  A13     : 0x3c2549f4  
A14     : 0x00000001  A15     : 0x00000010  SAR     : 0x00000008  EXCCAUSE: 0x0000001c  
EXCVADDR: 0x00010096  LBEG    : 0x420dd62e  LEND    : 0x420dd637  LCOUNT  : 0x00000000  

Backtrace: 0x4037e477:0x3fcc1c80 0x420af156:0x3fcc1ca0 0x421b5b0b:0x3fcc1ce0 0x42001b3e:0x3fcc1d00 0x42001729:0x3fcc1d40 0x420b700d:0x3fcc1d90 0x420bf731:0x3fcc1dc0 0x420bf7f9:0x3fcc1de0 0x40379aa2:0x3fcc1e00 0x420b6fb3:0x3fcc1ea0 0x420bf731:0x3fcc1f10 0x420bf7f9:0x3fcc1f30 0x40379aa2:0x3fcc1f50 0x420b6fb3:0x3fcc1ff0 0x420bf731:0x3fcc2020 0x420eb46b:0x3fcc2040 0x420eb4b5:0x3fcc2080 0x420bf731:0x3fcc20a0 0x4202313d:0x3fcc20c0 0x4203a9c5:0x3fcc2100 0x4203a935:0x3fcc2140 0x4203a109:0x3fcc2180 0x42039e85:0x3fcc21d0 0x42039bdb:0x3fcc2240 0x420395d7:0x3fcc2270 0x420771d1:0x3fcc22b0 0x42076db9:0x3fcc22f0 0x420063c1:0x3fcc2330 0x420282b1:0x3fcc2350 0x420064fd:0x3fcc2390 0x420bf731:0x3fcc23d0 0x420bf7f9:0x3fcc23f0 0x40379aa2:0x3fcc2410 0x420b6fb3:0x3fcc24b0 0x420bf731:0x3fcc24e0 0x420eb46b:0x3fcc2500 0x420eb4b5:0x3fcc2540 0x420bf731:0x3fcc2560 0x420bf7b9:0x3fcc2580 0x420c0378:0x3fcc25b0 0x420c04f5:0x3fcc2630 0x420d382b:0x3fcc2650 0x420c7b7d:0x3fcc2680 0x420b6e8d:0x3fcc26b0 0x420bf731:0x3fcc26d0 0x420bf7f9:0x3fcc26f0 0x40379aa2:0x3fcc2710 0x420b6fb3:0x3fcc27b0 0x420bf731:0x3fcc2800 0x420e9550:0x3fcc2820 0x420d79ad:0x3fcc28c0

ELF file SHA256: ce6a08fd0

Rebooting...
ESP-ROM:esp32s3-20210327
Build:Mar 27 2021
rst:0xc (RTC_SW_CPU_RST),boot:0xb (SPI_FAST_FLASH_BOOT)
Saved PC:0x40382ce6
SPIWP:0xee
mode:DIO, clock div:1
load:0x3fce3820,len:0x105c
load:0x403c9700,len:0x4
load:0x403c9704,len:0xbd8
load:0x403cc700,len:0x2e30
entry 0x403c989c
LVGL MicroPython 1.23.0 on 2024-08-05; Generic ESP32S3 module with Octal-SPIRAM with ESP32S3
Type "help()" for more information.
kdschlosser commented 1 month ago

This is what I would like you to do. I am going to key up a task handler module that doesn't use LVGL at all. I want to see if the problem still exists using just MicroPython. I have a feeling you are still going to end up with a crash even without LVGL being compiled into it.

I believe this is going to be an upstream bug in MicroPython. Just need to confirm it.

give me a little bit to write the task handler so it will run without LVGL.

jd3096-mpy commented 1 month ago

This is what I would like you to do. I am going to key up a task handler module that doesn't use LVGL at all. I want to see if the problem still exists using just MicroPython. I have a feeling you are still going to end up with a crash even without LVGL being compiled into it.

I believe this is going to be an upstream bug in MicroPython. Just need to confirm it.

give me a little bit to write the task handler so it will run without LVGL.

Thanks a lot. I user machine.timer instead of _thread, now it works.

kdschlosser commented 1 month ago

machine.timer is what is being used by task_handler. I had thought that machine.timer uses a hardware timer but it turns out it doesn't. It uses a software timer and I have not dove in to find out how it works.

kdschlosser commented 1 month ago

Here is the fix for this issue.

https://github.com/kdschlosser/lvgl_micropython/issues/92#issuecomment-2277066631

kdschlosser commented 1 week ago

@jd3096-mpy

Did that solve the problem with it crashing?

jd3096-mpy commented 1 week ago

@jd3096-mpy

Did that solve the problem with it crashing?

I use Timer instead

kdschlosser commented 1 week ago

If you could give it a try using the threads again except changing the stack size to something larger I would appreciate it. I would like to locate the root cause of the problem.

jd3096-mpy commented 1 week ago

If you could give it a try using the threads again except changing the stack size to something larger I would appreciate it. I would like to locate the root cause of the problem.

_thread.stack_size(10240) This line of code is indeed very effective. Even when I ran a relatively complex function in a thread, it still worked stably without crashing. However, on another S3 board I have, the thread works normally even without adding this line of code. Is there anything else you need me to test?

kdschlosser commented 1 week ago

I have not looked at how MicroPython sets the default stack size. I know it varies depending on the MCU being used. Less memory = smaller default stack size I am sure..

It's good to know that is what corrected your issue. I know you went a different route and managed to work around the issue but ideally threading is the way to go. I have started to mess about with getting the threads to run on both cores which would change about depending on the load of the cores. If i can get that working then threading is definitely going to be the thing to use...

kdschlosser commented 1 week ago

and the reason why you need to increase the stack size is because of LVGL.

jd3096-mpy commented 1 week ago

I have not looked at how MicroPython sets the default stack size. I know it varies depending on the MCU being used. Less memory = smaller default stack size I am sure..

It's good to know that is what corrected your issue. I know you went a different route and managed to work around the issue but ideally threading is the way to go. I have started to mess about with getting the threads to run on both cores which would change about depending on the load of the cores. If i can get that working then threading is definitely going to be the thing to use...

Once again, thank you for the tremendous contribution you've made to MicroPython LVGL. I had been following MicroPython LVGL for a long time before this repository came out. A few years ago, the official repository only supported the ESP32, and it took two years for unofficial contributors to solve the ESP32-S3 compatibility, and even then, it followed the traditional compilation route, which made setting up the environment particularly troublesome—one mistake and nothing would work. Now, with just a single command, automatic compilation is possible, which is incredibly convenient.

kdschlosser commented 1 week ago

That is exactly what I was going for when I wrote this. I wanted to take out all of the possible entry points for problems when compiling. Setting up the environment can be a tricky bit for new people and that is not what Python is all about. It is supposed to be easy to use. There is still some working through that I have to do with the display drivers and the touch drivers to make it more of a "single command". It seems that I need to make board specific setup files instead of display setup files. There is a learning curve to getting the settings right for a display driver.

That is something I am going to start working on. I want to use a simple yaml or toml file to hold different board setups where it will build the display driver and compile with all of the needed settings for a specific board.