Program crashes when adding wifi support

[cbarransunny]

Program crashes when adding wifi support

[stale]

This issue or pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[embeddedt]

Not stale. (I can't help with this issue as I don't use ESP32.)

[embeddedt]

@kisvegabor @amirgon Perhaps one of you can help with this?

[amirgon]

Where is the stack trace?
On a crash report, the very minimum is providing a parsed stack trace.

[justbarran]

Problem was solved by running Littlevgl only on core 1 while wifi and everything else runs on core 0. And using esp_timer_start_periodic(_lv_tick_timer, LV_TICK_MS*1000) to run the ticker.

[embeddedt]

It's probably a concurrency issue (LittlevGL needs you to wrap calls with some type of synchronization primitive to work with multithreaded systems).

[jeremyjh]

I should have noticed that just looking at this code, I had a similar thing happen to me. I use a pinned task to run the lv_task_handler(). I felt better about that approach than adding a mutex because there is absolutely no chance of a deadlock.

[justbarran]

Yea the main problem came from esp_register_freertos_tick_hook(lv_tick_task); This should never be used. And I used a Recursive mutex around the LittleVGL functions.

[monkeytronics]

Hey guys. I've just got this up and running on ESP32, but am crashing every couple of minutes... I am using esp_register_freertos_tick_hook(lv_tick_task); So, I guess I'm not doing it right?! I posted the stack trace and some extra info here:

espressif/esp-iot-solution#37 (comment)

Any chance you guys know what I'm doing wrong?? Thanks all.

[amirgon]

Any chance you guys know what I'm doing wrong?? Thanks all.

• One thing I don't understand about your code: from the stack trace it looks like ili9341_flush is calling vPortYield.
  However, I don't see where vPortYield is called anywhere in this project.
  Did you change ili9341? Where are your sources?

• Try to run it all on a single core (disable the second core when configuring ESP32) and check if the problem still happens. Even if the problem is still there, it would be easier to debug.

[monkeytronics]

Hmmm. I just downloaded the ili9341 code from here. I haven't touched it at all.

I've just built it again on a single core like you suggested. It's been running for a half hour now without crashing... It looks encouraging that you've fixed the immediate fault. Any idea why it might have been crashing with the dual core. Suggestions above that using esp_register_freertos_tick_hook(lv_tick_task) is a bad thing. Any clue as to why that is? Is there a better ESP32 approach somewhere? I don't really need the processing power as it happens, but keen to keep my code robust if possible...

Cheers,

[amirgon]

Hmmm. I just downloaded the ili9341 code from here. I haven't touched it at all.

Your stack trace:

0x4009742d: vPortYield at C:/msys32/home/thebi/esp/esp-idf/components/freertos/portasm.S:555
0x40142d70: ili9341_flush at C:/msys32/home/thebi/esp/esp-jumpstart/components/lvgl_ili9341/ili9341.c:130

Code from here:
https://github.com/littlevgl/lv_port_esp32_ili9341/blob/edf5bf19083e911876318c0842c091a6dfdc6d24/components/lvgl_ili9341/ili9341.c#L127-L137

That doesn't add up. line 130 on ili9341.c is an empty line, but on your stack trace it's calling vPortYield.
Are you aligned to HEAD?

Suggestions above that using esp_register_freertos_tick_hook(lv_tick_task) is a bad thing

I would try using xTimerCreate for calling lv_tick_inc, and xTaskCreate pinned to core for calling lv_task_handler (with some delay inside to yield).

I'm doing something like that on modlvesp32 (although I'm using micropython scheduler instead of xTaskCreate, but under the hoods micropython is calling xTaskCreate).

[stale]

This issue or pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.