Hello,
I've been able to reproduce the issue when adding flash support to the sdk's "lvgl demo widgets" example.
When a flash erase command is sent via spi while lvgl is running the application halts. The debugger usually ends up breaking outside of the application memory, but is sometimes caught in the stack overflow fault handler. By significantly increasing the size of the lvgl task's stack, it will sometimes not crash.
This issue will not occur for for any erase commands executed before the lvgl task is started and doesn't seem to occur on any other non-erase spi flash commands after lvgl has started. Though the erase command seems to take significantly longer to finish than the other commands.
We are using the fsl flexspi driver and a touch panel that is working with the example's RK043FN02H preset.
Thank you
Hi Jing,
Thank you for your insight. I have confirmed that linking the application to RAM does fix the issue.
Do you have any examples or documentation of how I would go about loading an application from flash into RAM? I see that MCUXpresso provides a "Plain load image" linker option, which seems to be what I'm looking for. But I haven't been able to find how to make use it.
Thank you,
Jared
Hi @jbutcher ,
Don't use "plain load image". It is for LPC MCU only. You can just link to SRAM, add header( FCB and IVT). ROM boot will check the image and copy you application to RAM. Please refer to Figure 9-3.
Regards,
Jing
Hi @jbutcher ,
The flexspi and flash doesn't support RWW (read while write). Some times it can work because RT1060 has i-cache which cached code. But if lvgl need some data in flash not cached, it will crash.
Regards,
Jing
Hi NXP Team, @jingpan,
Here we are also facing same issue during FlexSPI read write with LVGL running on IMXRT1170 board and the LVGL is crashing suddenly.
Is it related to SPI RWW(read while write) limitation on SPI? If yes how to resolve this issue? Please suggest us how to proceed further.
Regards,
Prashanth