search

lvgl-micropython / lvgl_micropython

LVGL module for MicroPython
MIT License
86 stars 27 forks source link

SPI Exception #167

Open wxzed opened 3 weeks ago

wxzed commented 3 weeks ago

My code looks like this, and when I use the modified API, I found that it causes the ESP32-S3 to restart directly: from machine import SPI sd_spi_bus = SPI.Bus(host=1, mosi=42, miso=41, sck=44) sd_spi_device = SPI.Device(spi_bus=sd_spi_bus, freq=1000000, cs=40, polarity=0, phase=0) sd_spi_device.init()

wxzed commented 3 weeks ago 
from machine import SPI
sd_spi_bus = SPI.Bus(host=1, mosi=42, miso=41, sck=44)
sd_spi_device = SPI.Device(spi_bus=sd_spi_bus, freq=1000000, cs=40, polarity=0, phase=0)
sd_spi_device.init()
wxzed commented 3 weeks ago

MPY: soft reboot

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-10-31 IDF version : v5.2-dirty Machine : Generic ESP32S3 module with Octal-SPIRAM with ESP32S3

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

Core 1 register dump: PC : 0x00000000 PS : 0x00060630 A0 : 0x820b19fc A1 : 0x3fcbd650
A2 : 0x00000006 A3 : 0x3c251478 A4 : 0x3fcbd670 A5 : 0x00000000
A6 : 0x00000001 A7 : 0x3fcbda60 A8 : 0x821b59f8 A9 : 0x3c22243c
A10 : 0x3c250f90 A11 : 0x00000000 A12 : 0x3c25147c A13 : 0x3fcbd670
A14 : 0x00000001 A15 : 0x00000006 SAR : 0x00000000 EXCCAUSE: 0x00000014
EXCVADDR: 0x00000000 LBEG : 0x400570e8 LEND : 0x400570f3 LCOUNT : 0x00000000

kdschlosser commented 3 weeks ago

the init method doesn't need to be called. it is actually a do nothing function. It is supposed to simply exit and not cause a reboot of the ESP. I will have to look into why it is doing that. There really is no reason to use the init function. It's purpose was to shut down the bus and restart it when wanting to communicate to a different device but because of how the new system is written there is no longer a need to do that to change devices because you are able to define individual devices and it changes between them automatically when sensing or receiving data.

wxzed commented 3 weeks ago

Since my previous program included init, using it directly would cause a reset. After identifying that init was the issue, I removed it, but then I found that the program would get stuck at write(buf).

wxzed commented 3 weeks ago

In short, I can't simply change machine.SPI to machine.SPI.Device to make the previous SPI program work.

kdschlosser commented 3 weeks ago

I don't know exactly what you are trying to do to make it work. Are there other devices on the same bus? did you pass a CS pin for each devise on the bus?

wxzed commented 3 weeks ago

This has nothing to do with the display; I just want to drive some standard SPI sensors. However, I found that the SPI usage is different from before, so I haven't been able to drive them successfully.

kdschlosser commented 2 weeks ago

if you add --debug to the build command it will enable all the debug logging output in the ESP-IDF and that might shed some light as to what is going on and where it is happening. It is probably something silly that I made a mistake on or overlooked.